diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md
index 48ceb2a56..2ea4788d7 100644
--- a/docs/uk/help/testing.md
+++ b/docs/uk/help/testing.md
@@ -2,104 +2,104 @@
read_when:
- Запуск тестів локально або в CI
- Додавання регресійних тестів для помилок моделей/провайдерів
- - Налагодження поведінки Gateway та агента
-summary: 'Комплект тестування: набори unit/e2e/live, ранери Docker і те, що охоплює кожен тест'
+ - Налагодження поведінки Gateway + агента
+summary: 'Набір для тестування: unit/e2e/live-набори, Docker-ранери та що покриває кожен тест'
title: Тестування
x-i18n:
- generated_at: "2026-05-04T22:29:46Z"
+ generated_at: "2026-05-04T23:56:27Z"
model: gpt-5.5
provider: openai
- source_hash: 0262d0bc9302671513cec25c8e7ae9c4b4f495ab8d4fd9a01ac3ce0ab94d476b
+ source_hash: 8d051bf6a01f6caf7755ad1d7107f21ae2d440b55a65bb7f18ee4a81f5f0e3b2
source_path: help/testing.md
workflow: 16
---
-OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір
+OpenClaw має три набори тестів Vitest (модульні/інтеграційні, e2e, live) і невеликий набір
Docker-ранерів. Цей документ є посібником «як ми тестуємо»:
-- Що охоплює кожен набір (і що він навмисно _не_ охоплює).
-- Які команди запускати для поширених робочих процесів (локально, перед push, налагодження).
-- Як live-тести знаходять облікові дані та вибирають моделі/провайдерів.
+- Що покриває кожен набір тестів (і що він навмисно _не_ покриває).
+- Які команди запускати для типових робочих процесів (локально, перед push, під час налагодження).
+- Як live-тести виявляють облікові дані та вибирають моделі/провайдерів.
- Як додавати регресійні тести для реальних проблем із моделями/провайдерами.
-**QA-стек (qa-lab, qa-channel, live-транспортні смуги)** задокументовано окремо:
+**QA-стек (qa-lab, qa-channel, live transport lanes)** документовано окремо:
- [Огляд QA](/uk/concepts/qa-e2e-automation) — архітектура, поверхня команд, створення сценаріїв.
- [Matrix QA](/uk/concepts/qa-matrix) — довідник для `pnpm openclaw qa matrix`.
-- [QA-канал](/uk/channels/qa-channel) — синтетичний транспортний plugin, який використовується сценаріями на основі репозиторію.
+- [QA channel](/uk/channels/qa-channel) — синтетичний транспортний Plugin, який використовується сценаріями з репозиторію.
-Ця сторінка охоплює запуск звичайних тестових наборів і Docker/Parallels-ранерів. Розділ про QA-специфічні ранери нижче ([QA-специфічні ранери](#qa-specific-runners)) перелічує конкретні виклики `qa` і відсилає до наведених вище довідників.
+Ця сторінка описує запуск звичайних наборів тестів і Docker/Parallels-ранерів. Розділ про QA-специфічні ранери нижче ([QA-специфічні ранери](#qa-specific-runners)) перелічує конкретні виклики `qa` і повертає до наведених вище довідників.
## Швидкий старт
-У більшості випадків:
+У більшість днів:
- Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test`
-- Швидший локальний запуск повного набору на машині з достатніми ресурсами: `pnpm test:max`
-- Прямий цикл спостереження Vitest: `pnpm test:watch`
-- Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts`
-- Спершу віддавайте перевагу цільовим запускам, коли ітеруєтеся над одним збоєм.
-- QA-сайт на основі Docker: `pnpm qa:lab:up`
-- QA-смуга на основі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline`
+- Швидший локальний запуск повного набору тестів на просторій машині: `pnpm test:max`
+- Прямий цикл Vitest watch: `pnpm test:watch`
+- Пряме націлювання на файл тепер також маршрутизує шляхи розширень/каналів: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts`
+- Спершу надавайте перевагу цільовим запускам, коли ітеруєте над одним падінням.
+- QA-сайт на базі Docker: `pnpm qa:lab:up`
+- QA-смуга на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline`
-Коли ви змінюєте тести або хочете додаткової впевненості:
+Коли ви торкаєтеся тестів або хочете додаткової впевненості:
- Gate покриття: `pnpm test:coverage`
- Набір E2E: `pnpm test:e2e`
Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані):
-- Live-набір (моделі + проби інструментів/зображень gateway): `pnpm test:live`
+- Live-набір (моделі + перевірки інструментів/зображень Gateway): `pnpm test:live`
- Тихо націлити один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts`
-- Звіти про продуктивність runtime: dispatch `OpenClaw Performance` з
+- Звіти про продуктивність під час виконання: запустіть `OpenClaw Performance` з
`live_gpt54=true` для реального ходу агента `openai/gpt-5.4` або
`deep_profile=true` для артефактів CPU/heap/trace Kova. Щоденні заплановані запуски
публікують артефакти смуг mock-provider, deep-profile і GPT 5.4 до
`openclaw/clawgrit-reports`, коли налаштовано `CLAWGRIT_REPORTS_TOKEN`. Звіт
- mock-provider також містить показники завантаження gateway на рівні джерела, пам’яті,
- plugin-pressure, повторюваного fake-model hello-loop і старту CLI.
-- Live-перевірка моделей у Docker: `pnpm test:docker:live-models`
- - Кожна вибрана модель тепер виконує текстовий хід плюс невелику пробу в стилі читання файлу.
+ mock-provider також включає показники завантаження Gateway на рівні джерел, пам’яті,
+ Plugin-pressure, повторюваного fake-model hello-loop і старту CLI.
+- Docker live model sweep: `pnpm test:docker:live-models`
+ - Кожна вибрана модель тепер виконує текстовий хід і невелику перевірку в стилі читання файлу.
Моделі, метадані яких оголошують вхід `image`, також виконують крихітний хід із зображенням.
- Вимикайте додаткові проби за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або
- `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера.
+ Вимкніть додаткові перевірки через `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 з
- `include_live_suites: true`, що включає окремі Docker live model
- matrix jobs, шардовані за провайдером.
+ `OpenClaw Release Checks` обидва викликають багаторазовий live/E2E workflow з
+ `include_live_suites: true`, що включає окремі Docker live model matrix jobs,
+ розбиті за провайдером.
- Для сфокусованих повторних запусків CI запустіть `OpenClaw Live And E2E Checks (Reusable)`
з `include_live_suites: true` і `live_models_only: true`.
- - Додавайте нові high-signal секрети провайдерів до `scripts/ci-hydrate-live-auth.sh`
+ - Додайте нові високосигнальні секрети провайдера до `scripts/ci-hydrate-live-auth.sh`
плюс `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` та його
- scheduled/release викликачів.
+ запланованих/release-викликачів.
- Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind`
- - Запускає Docker live-смугу проти шляху Codex app-server, прив’язує синтетичний
- Slack DM за допомогою `/codex bind`, перевіряє `/codex fast` і
- `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення зображення
- проходять через native plugin binding замість ACP.
+ - Запускає Docker live lane проти шляху app-server Codex, прив’язує синтетичний
+ Slack DM через `/codex bind`, виконує `/codex fast` і
+ `/codex permissions`, потім перевіряє, що звичайна відповідь і вкладення зображення
+ проходять через нативну прив’язку Plugin замість ACP.
- Codex app-server harness smoke: `pnpm test:docker:live-codex-harness`
- - Запускає ходи gateway agent через належний plugin harness Codex app-server,
- перевіряє `/codex status` і `/codex models`, а за замовчуванням виконує проби image,
- cron MCP, sub-agent і Guardian. Вимикайте пробу sub-agent за допомогою
- `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші збої Codex
- app-server. Для сфокусованої перевірки sub-agent вимкніть інші проби:
+ - Запускає ходи агента Gateway через harness app-server Codex, який належить Plugin,
+ перевіряє `/codex status` і `/codex models`, а за замовчуванням виконує перевірки image,
+ cron MCP, sub-agent і Guardian. Вимкніть перевірку sub-agent через
+ `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші падіння Codex
+ app-server. Для сфокусованої перевірки sub-agent вимкніть інші перевірки:
`OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`.
- Це завершується після проби sub-agent, якщо не встановлено
+ Це завершується після перевірки sub-agent, якщо не встановлено
`OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`.
- Crestodian rescue command smoke: `pnpm test:live:crestodian-rescue-channel`
- - Opt-in перевірка з подвійним захистом для поверхні команди порятунку message-channel.
+ - Додаткова ретельна перевірка поверхні rescue-команди каналу повідомлень.
Вона виконує `/crestodian status`, ставить у чергу постійну зміну моделі,
- відповідає `/crestodian yes` і перевіряє шлях audit/config write.
+ відповідає `/crestodian yes` і перевіряє шлях запису audit/config.
- Crestodian planner Docker smoke: `pnpm test:docker:crestodian-planner`
- - Запускає Crestodian у контейнері без конфігурації з фейковим Claude CLI на `PATH`
+ - Запускає Crestodian у контейнері без конфігурації з підробленим Claude CLI у `PATH`
і перевіряє, що нечіткий fallback планувальника перетворюється на аудитований типізований
запис конфігурації.
- Crestodian first-run Docker smoke: `pnpm test:docker:crestodian-first-run`
- - Починає з порожньої директорії стану OpenClaw, маршрутизує голий `openclaw` до
- Crestodian, застосовує записи setup/model/agent/Discord plugin + SecretRef,
- валідовує конфігурацію та перевіряє audit entries. Той самий шлях налаштування Ring 0
+ - Починає з порожнього каталогу стану OpenClaw, маршрутизує голий `openclaw` до
+ Crestodian, застосовує записи setup/model/agent/Discord Plugin + SecretRef,
+ перевіряє конфігурацію й перевіряє audit entries. Той самий шлях налаштування Ring 0
також покрито в QA Lab через
`pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`.
- Moonshot/Kimi cost smoke: з установленим `MOONSHOT_API_KEY` запустіть
@@ -109,124 +109,124 @@ Docker-ранерів. Цей документ є посібником «як м
транскрипт асистента зберігає нормалізований `usage.cost`.
-Коли вам потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через env vars allowlist, описані нижче.
+Коли вам потрібен лише один випадок падіння, надавайте перевагу звуженню live-тестів через env vars allowlist, описані нижче.
## QA-специфічні ранери
-Ці команди розташовані поруч із основними тестовими наборами, коли вам потрібна реалістичність QA-lab:
+Ці команди розташовані поруч із головними наборами тестів, коли потрібен реалізм QA-lab:
-CI запускає QA Lab у спеціальних workflow. Agentic parity вкладено під
-`QA-Lab - All Lanes` і release validation, а не окремий PR workflow.
+CI запускає QA Lab у dedicated workflows. Agentic parity вкладено під
+`QA-Lab - All Lanes` і release validation, а не в окремий PR workflow.
Для широкої валідації слід використовувати `Full Release Validation` з
-`rerun_group=qa-parity` або QA-групу release-checks. Stable/default release
-checks тримають вичерпний live/Docker soak за `run_release_soak=true`; профіль
+`rerun_group=qa-parity` або групу QA release-checks. Стабільні/типові release
+checks тримають exhaustive live/Docker soak за `run_release_soak=true`; профіль
`full` примусово вмикає soak. `QA-Lab - All Lanes`
запускається щоночі на `main` і з ручного dispatch із mock parity lane, live
Matrix lane, Convex-managed live Telegram lane і Convex-managed live Discord
-lane як паралельні jobs. Scheduled QA і release checks явно передають Matrix
+lane як паралельними jobs. Заплановані QA та release checks явно передають Matrix
`--profile fast`, тоді як Matrix CLI і manual workflow input
-за замовчуванням лишаються `all`; manual dispatch може шардити `all` на jobs
+за замовчуванням лишаються `all`; ручний dispatch може розбити `all` на jobs
`transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release
Checks` запускає parity плюс fast Matrix і Telegram lanes перед release
approval, використовуючи `mock-openai/gpt-5.5` для release transport checks, щоб вони лишалися
-детермінованими й уникали звичайного старту provider-plugin. Ці live transport
-gateways вимикають пошук у пам’яті; поведінка пам’яті лишається покритою QA parity
+детермінованими та уникали звичайного запуску provider-plugin. Ці live transport
+gateways вимикають memory search; поведінка пам’яті лишається покритою QA parity
suites.
Full release live media shards використовують
`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, який уже має
`ffmpeg` і `ffprobe`. Docker live model/backend shards використовують спільний
образ `ghcr.io/openclaw/openclaw-live-test:`, зібраний один раз для вибраного
-commit, а потім завантажують його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість повторної збірки
+коміту, а потім отримують його через `OPENCLAW_SKIP_DOCKER_BUILD=1` замість повторної збірки
всередині кожного shard.
- `pnpm openclaw qa suite`
- - Запускає QA-сценарії з репозиторію безпосередньо на хості.
+ - Запускає QA-сценарії, підтримані репозиторієм, безпосередньо на хості.
- За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими
- працівниками Gateway. `qa-channel` за замовчуванням використовує паралельність 4 (обмежено
- кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати кількість
- працівників, або `--concurrency 1` для старішої послідовної смуги.
- - Завершується з ненульовим кодом, якщо будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли вам
- потрібні артефакти без коду завершення, що означає помилку.
+ Gateway-працівниками. `qa-channel` за замовчуванням має паралельність 4 (обмежену
+ кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати
+ кількість працівників, або `--concurrency 1` для старішої послідовної гілки.
+ - Завершується з ненульовим кодом, якщо будь-який сценарій не вдається. Використовуйте `--allow-failures`, коли
+ потрібні артефакти без коду виходу, що позначає помилку.
- Підтримує режими провайдера `live-frontier`, `mock-openai` і `aimock`.
`aimock` запускає локальний сервер провайдера на базі AIMock для експериментального
- покриття фікстур і моків протоколу, не замінюючи смугу `mock-openai`, яка враховує сценарії.
+ покриття фікстур і моків протоколу без заміни гілки `mock-openai`, обізнаної зі сценаріями.
- `pnpm test:plugins:kitchen-sink-live`
- - Запускає живий прогін Plugin OpenAI Kitchen Sink через QA Lab. Він
- встановлює зовнішній пакет Kitchen Sink, перевіряє інвентар поверхні plugin SDK,
+ - Запускає живий набір випробувань OpenAI Kitchen Sink Plugin через QA Lab. Він
+ установлює зовнішній пакет Kitchen Sink, перевіряє інвентар поверхні SDK Plugin,
зондує `/healthz` і `/readyz`, записує докази CPU/RSS Gateway,
- запускає живий хід OpenAI і перевіряє змагальну діагностику.
- Потребує живої автентифікації OpenAI, наприклад `OPENAI_API_KEY`. У гідратованих сесіях Testbox
- автоматично підтягує live-auth профіль Testbox, коли
- наявний помічник `openclaw-testbox-env`.
+ виконує живий хід OpenAI і перевіряє змагальну діагностику.
+ Потребує живої автентифікації OpenAI, наприклад `OPENAI_API_KEY`. У гідратованих сеансах Testbox
+ він автоматично підвантажує профіль live-auth Testbox, коли наявний
+ помічник `openclaw-testbox-env`.
- `pnpm test:gateway:cpu-scenarios`
- - Запускає бенч старту Gateway плюс невеликий пакет mock-сценаріїв QA Lab
+ - Запускає бенч запуску Gateway плюс невеликий пакет мок-сценаріїв QA Lab
(`channel-chat-baseline`, `memory-failure-fallback`,
- `gateway-restart-inflight-run`) і записує зведення комбінованих спостережень CPU
+ `gateway-restart-inflight-run`) і записує зведений підсумок спостережень CPU
у `.artifacts/gateway-cpu-scenarios/`.
- - За замовчуванням позначає лише тривалі спостереження гарячого CPU (`--cpu-core-warn`
- плюс `--hot-wall-warn-ms`), тому короткі сплески під час старту записуються як метрики
- без вигляду регресії Gateway із навантаженням на хвилини.
- - Використовує зібрані артефакти `dist`; спершу запустіть збірку, якщо в checkout ще немає
- свіжого runtime-виводу.
+ - За замовчуванням позначає лише сталі спостереження гарячого CPU (`--cpu-core-warn`
+ плюс `--hot-wall-warn-ms`), тому короткі сплески під час запуску записуються як метрики
+ і не виглядають як регресія з багатохвилинним навантаженням Gateway.
+ - Використовує зібрані артефакти `dist`; спершу запустіть збірку, якщо checkout ще не
+ має свіжого runtime-виводу.
- `pnpm openclaw qa suite --runner multipass`
- - Запускає той самий QA-набір у одноразовій Linux VM Multipass.
+ - Запускає той самий QA-набір усередині одноразової Linux-VM Multipass.
- Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
- Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`.
- - Живі запуски передають підтримувані вхідні дані QA-автентифікації, практичні для гостя:
- ключі провайдера з env, шлях до конфігу QA live provider і `CODEX_HOME`,
+ - Живі запуски передають підтримувані вхідні дані автентифікації QA, практичні для гостя:
+ ключі провайдера на базі env, шлях до конфігурації живого провайдера QA та `CODEX_HOME`,
коли він наявний.
- - Каталоги виводу мають залишатися під коренем репозиторію, щоб гість міг записувати назад через
- змонтований workspace.
- - Записує звичайний QA-звіт + зведення, а також логи Multipass у
+ - Каталоги виводу мають залишатися в корені репозиторію, щоб гість міг записувати назад через
+ змонтований робочий простір.
+ - Записує звичайний QA-звіт + підсумок, а також журнали Multipass у
`.artifacts/qa-e2e/...`.
- `pnpm qa:lab:up`
- - Запускає QA-сайт на базі Docker для operator-style QA-роботи.
+ - Запускає Docker-підтриманий QA-сайт для операторської QA-роботи.
- `pnpm test:docker:npm-onboard-channel-agent`
- - Збирає npm tarball із поточного checkout, встановлює його глобально в
- Docker, запускає неінтерактивний onboarding з API-ключем OpenAI, за замовчуванням налаштовує Telegram,
- перевіряє, що запакований runtime Plugin завантажується без виправлення залежностей під час старту,
- запускає doctor і запускає один локальний хід агента проти
- змокованого endpoint OpenAI.
- - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму смугу packaged-install
+ - Збирає npm tarball із поточного checkout, установлює його глобально в
+ Docker, запускає неінтерактивний onboarding із API-ключем OpenAI, за замовчуванням налаштовує Telegram,
+ перевіряє, що запакований Plugin runtime завантажується без відновлення залежностей під час запуску,
+ запускає doctor і виконує один локальний хід агента проти
+ замоканого endpoint OpenAI.
+ - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму гілку packaged-install
з Discord.
- `pnpm test:docker:session-runtime-context`
- - Запускає детермінований Docker smoke для зібраного застосунку щодо транскриптів вбудованого runtime-контексту.
+ - Запускає детермінований Docker smoke зібраного застосунку для вбудованих транскриптів runtime-контексту.
Він перевіряє, що прихований runtime-контекст OpenClaw зберігається як
- non-display custom message замість витоку у видимий хід користувача,
- потім засіває уражений зламаний session JSONL і перевіряє, що
+ custom message, який не відображається, замість витоку у видимий хід користувача,
+ потім засіває зачеплений зламаний session JSONL і перевіряє, що
`openclaw doctor --fix` переписує його на активну гілку з резервною копією.
- `pnpm test:docker:npm-telegram-live`
- - Встановлює candidate-пакет OpenClaw у Docker, запускає onboarding встановленого пакета,
- налаштовує Telegram через встановлений CLI, а потім повторно використовує
- живу QA-смугу Telegram з цим встановленим пакетом як SUT Gateway.
+ - Установлює candidate-пакет OpenClaw у Docker, запускає onboarding установленого пакета,
+ налаштовує Telegram через установлений CLI, а потім повторно використовує
+ живу Telegram QA-гілку з цим установленим пакетом як SUT Gateway.
- За замовчуванням використовує `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; задайте
`OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` або
`OPENCLAW_CURRENT_PACKAGE_TGZ`, щоб тестувати розв’язаний локальний tarball замість
- встановлення з реєстру.
+ установлення з registry.
- Використовує ті самі env-облікові дані Telegram або джерело облікових даних Convex, що й
- `pnpm openclaw qa telegram`. Для автоматизації CI/релізів задайте
+ `pnpm openclaw qa telegram`. Для CI/release-автоматизації задайте
`OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` плюс
`OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі. Якщо
`OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі Convex наявні в CI,
Docker-обгортка автоматично вибирає Convex.
- - Обгортка перевіряє env облікових даних Telegram або Convex на хості до
- роботи Docker build/install. Задавайте `OPENCLAW_NPM_TELEGRAM_SKIP_CREDENTIAL_PREFLIGHT=1`
- лише коли навмисно налагоджуєте підготовку до налаштування облікових даних.
+ - Обгортка перевіряє env облікових даних Telegram або Convex на хості перед
+ роботою Docker build/install. Задавайте `OPENCLAW_NPM_TELEGRAM_SKIP_CREDENTIAL_PREFLIGHT=1`
+ лише під час навмисного налагодження підготовки до облікових даних.
- `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільну
- `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї смуги.
- - GitHub Actions надає цю смугу як ручний maintainer workflow
+ `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї гілки.
+ - GitHub Actions надає цю гілку як ручний maintainer workflow
`NPM Telegram Beta E2E`. Він не запускається під час merge. Workflow використовує
- середовище `qa-live-shared` і CI-оренди облікових даних Convex.
-- GitHub Actions також надає `Package Acceptance` для side-run product proof
- проти одного candidate-пакета. Він приймає довірений ref, опублікований npm spec,
- HTTPS tarball URL плюс SHA-256 або tarball-артефакт з іншого запуску, завантажує
+ середовище `qa-live-shared` і lease-и CI-облікових даних Convex.
+- GitHub Actions також надає `Package Acceptance` для побічного product proof
+ проти одного candidate-пакета. Він приймає довірений ref, опубліковану npm spec,
+ HTTPS tarball URL плюс SHA-256 або tarball artifact з іншого запуску, завантажує
нормалізований `openclaw-current.tgz` як `package-under-test`, а потім запускає
- наявний Docker E2E scheduler з профілями smoke, package, product, full або custom
- lane. Задайте `telegram_mode=mock-openai` або `live-frontier`, щоб запустити
+ наявний Docker E2E scheduler із профілями гілок smoke, package, product, full або custom.
+ Задайте `telegram_mode=mock-openai` або `live-frontier`, щоб запустити
Telegram QA workflow проти того самого артефакту `package-under-test`.
- - Product proof для останньої beta:
+ - Доказ останньої beta продукту:
```bash
gh workflow run package-acceptance.yml --ref main \
@@ -236,7 +236,7 @@ gh workflow run package-acceptance.yml --ref main \
-f telegram_mode=mock-openai
```
-- Proof точного tarball URL потребує digest:
+- Доказ точного tarball URL потребує digest:
```bash
gh workflow run package-acceptance.yml --ref main \
@@ -246,7 +246,7 @@ gh workflow run package-acceptance.yml --ref main \
-f suite_profile=package
```
-- Artifact proof завантажує tarball-артефакт з іншого запуску Actions:
+- Доказ артефакту завантажує tarball artifact з іншого запуску Actions:
```bash
gh workflow run package-acceptance.yml --ref main \
@@ -258,74 +258,74 @@ gh workflow run package-acceptance.yml --ref main \
- `pnpm test:docker:plugins`
- Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway
- з налаштованим OpenAI, а потім вмикає вбудовані channel/plugins через редагування
- конфігу.
- - Перевіряє, що setup discovery залишає неналаштовані завантажувані plugins відсутніми,
- перше налаштоване doctor repair явно встановлює кожен відсутній завантажуваний
- plugin, а другий restart не запускає приховане виправлення
+ з налаштованим OpenAI, а потім вмикає bundled channel/plugins через
+ редагування конфігурації.
+ - Перевіряє, що setup discovery залишає неналаштовані downloadable plugins відсутніми,
+ перше налаштоване відновлення doctor явно встановлює кожен відсутній downloadable
+ plugin, а другий перезапуск не виконує прихованого відновлення
залежностей.
- - Також встановлює відомий старіший npm baseline, вмикає Telegram перед запуском
- `openclaw update --tag ` і перевіряє, що
- post-update doctor candidate очищує legacy debris залежностей plugin без
- harness-side postinstall repair.
+ - Також установлює відому старішу npm baseline, вмикає Telegram перед запуском
+ `openclaw update --tag ` і перевіряє, що post-update doctor candidate
+ очищає залишки застарілих залежностей Plugin без
+ postinstall-відновлення з боку harness.
- `pnpm test:parallels:npm-update`
- - Запускає нативний packaged-install update smoke на гостях Parallels. Кожна
+ - Запускає native packaged-install update smoke на гостьових системах Parallels. Кожна
вибрана платформа спочатку встановлює запитаний baseline-пакет, потім запускає
- встановлену команду `openclaw update` у тому самому гості й перевіряє
- встановлену версію, статус оновлення, готовність Gateway і один локальний
- хід агента.
+ встановлену команду `openclaw update` у тому самому гості та перевіряє
+ встановлену версію, статус оновлення, готовність Gateway і один локальний хід
+ агента.
- Використовуйте `--platform macos`, `--platform windows` або `--platform linux` під час
- ітерацій на одному гості. Використовуйте `--json` для шляху до summary artifact і
- статусу за смугами.
- - Смуга OpenAI за замовчуванням використовує `openai/gpt-5.5` для proof живого agent-turn.
+ ітерацій на одному гості. Використовуйте `--json` для шляху артефакту підсумку та
+ статусу кожної гілки.
+ - Гілка OpenAI за замовчуванням використовує `openai/gpt-5.5` для живого доказу ходу агента.
Передайте `--model ` або задайте
`OPENCLAW_PARALLELS_OPENAI_MODEL`, коли навмисно перевіряєте іншу
модель OpenAI.
- - Обгортайте довгі локальні запуски в host timeout, щоб зависання транспорту Parallels не
- використали решту тестового вікна:
+ - Обгортайте довгі локальні запуски timeout на хості, щоб зависання транспорту Parallels не могли
+ витратити решту вікна тестування:
```bash
timeout --foreground 150m pnpm test:parallels:npm-update -- --json
timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json
```
- - Скрипт записує вкладені логи смуг у `/tmp/openclaw-parallels-npm-update.*`.
- Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log`
- перед тим, як припускати, що зовнішня обгортка зависла.
- - Оновлення Windows може витратити 10-15 хвилин на post-update doctor і роботу
- з оновлення package на холодному гості; це все ще нормально, якщо вкладений npm
+ - Скрипт записує вкладені журнали гілок у `/tmp/openclaw-parallels-npm-update.*`.
+ Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log`,
+ перш ніж припускати, що зовнішня обгортка зависла.
+ - Windows update може витрачати 10-15 хвилин на post-update doctor і роботу
+ оновлення пакета на cold guest; це все ще нормально, коли вкладений npm
debug log просувається.
- - Не запускайте цю агреговану обгортку паралельно з окремими смугами smoke Parallels
- для macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час
- відновлення snapshot, подавання package або стану guest Gateway.
- - Post-update proof запускає звичайну поверхню вбудованих plugins, тому що
- capability facades, такі як мовлення, генерація зображень і розуміння медіа,
- завантажуються через вбудовані runtime APIs, навіть коли сам хід агента
+ - Не запускайте цю агрегатну обгортку паралельно з окремими Parallels
+ macOS, Windows або Linux smoke-гілками. Вони спільно використовують стан VM і можуть конфліктувати під час
+ відновлення snapshot, обслуговування пакета або стану гостьового Gateway.
+ - Post-update proof запускає звичайну поверхню bundled Plugin, тому що
+ фасади можливостей, як-от speech, image generation і media
+ understanding, завантажуються через bundled runtime APIs, навіть коли сам хід агента
перевіряє лише просту текстову відповідь.
- `pnpm openclaw qa aimock`
- Запускає лише локальний сервер провайдера AIMock для прямого protocol smoke
testing.
- `pnpm openclaw qa matrix`
- - Запускає живу QA-смугу Matrix проти одноразового Tuwunel homeserver на базі Docker. Лише source-checkout — packaged installs не постачають `qa-lab`.
- - Повний CLI, каталог профілів/сценаріїв, env vars і структура артефактів: [Matrix QA](/uk/concepts/qa-matrix).
+ - Запускає живу QA-гілку Matrix проти одноразового Docker-підтриманого Tuwunel homeserver. Лише source-checkout — packaged installs не постачають `qa-lab`.
+ - Повний CLI, каталог profile/scenario, env vars і layout артефактів: [Matrix QA](/uk/concepts/qa-matrix).
- `pnpm openclaw qa telegram`
- - Запускає живу QA-смугу Telegram проти справжньої приватної групи з використанням токенів driver і SUT bot з env.
+ - Запускає живу QA-гілку Telegram проти реальної приватної групи з використанням токенів driver і SUT bot з env.
- Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Group id має бути числовим Telegram chat id.
- - Підтримує `--credential-source convex` для спільних pooled credentials. Використовуйте env mode за замовчуванням або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases.
- - Завершується з ненульовим кодом, якщо будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли вам
- потрібні артефакти без коду завершення, що означає помилку.
- - Потребує двох окремих bots в одній приватній групі, причому SUT bot має надавати Telegram username.
- - Для стабільного bot-to-bot observation увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bots і переконайтеся, що driver bot може спостерігати group bot traffic.
- - Записує Telegram QA report, summary і observed-messages artifact у `.artifacts/qa-e2e/...`. Сценарії з відповіддю включають RTT від send request драйвера до спостереженої відповіді SUT.
+ - Підтримує `--credential-source convex` для спільних pooled credentials. За замовчуванням використовуйте env mode або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases.
+ - Завершується з ненульовим кодом, якщо будь-який сценарій не вдається. Використовуйте `--allow-failures`, коли потрібні
+ артефакти без коду виходу, що позначає помилку.
+ - Потребує двох окремих bot в одній приватній групі, причому SUT bot має надавати Telegram username.
+ - Для стабільного bot-to-bot спостереження увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bot і переконайтеся, що driver bot може спостерігати груповий bot traffic.
+ - Записує Telegram QA report, summary і артефакт observed-messages у `.artifacts/qa-e2e/...`. Replying scenarios включають RTT від driver send request до observed SUT reply.
-Живі transport lanes мають один стандартний контракт, щоб нові transports не розходилися; per-lane coverage matrix розміщена в [Огляд QA → Покриття живого транспорту](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий синтетичний набір і не є частиною цієї matrix.
+Живі транспортні гілки мають один стандартний контракт, щоб нові транспорти не розходилися; матриця покриття кожної гілки міститься в [огляді QA → Покриття живого транспорту](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` є широким синтетичним набором і не входить до цієї матриці.
### Спільні облікові дані Telegram через Convex (v1)
-Коли `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) увімкнено для
-`openclaw qa telegram`, QA lab отримує ексклюзивну lease з pool на базі Convex, надсилає heartbeats
-для цієї lease, поки смуга виконується, і звільняє lease під час shutdown.
+Коли для `openclaw qa telegram` увімкнено `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`),
+QA lab отримує ексклюзивний lease з pool на базі Convex, надсилає heartbeats
+для цього lease, поки гілка виконується, і звільняє lease під час shutdown.
Еталонний scaffold проєкту Convex:
@@ -333,7 +333,7 @@ gh workflow run package-acceptance.yml --ref main \
Обов’язкові env vars:
-- `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад `https://your-deployment.convex.site`)
+- `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад, `https://your-deployment.convex.site`)
- Один секрет для вибраної ролі:
- `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` для `maintainer`
- `OPENCLAW_QA_CONVEX_SECRET_CI` для `ci`
@@ -349,11 +349,11 @@ gh workflow run package-acceptance.yml --ref main \
- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (за замовчуванням `15000`)
- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (за замовчуванням `/qa-credentials/v1`)
- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов’язковий trace id)
-- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` Convex URLs для local-only development.
+- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` Convex URLs лише для локальної розробки.
-`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` за нормальної роботи.
+`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` у звичайній роботі.
-Адміністративні команди супровідників (pool add/remove/list) потребують саме
+Адміністративні команди супровідників (pool add/remove/list) вимагають саме
`OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`.
CLI-помічники для супровідників:
@@ -365,12 +365,12 @@ pnpm openclaw qa credentials list --kind telegram
pnpm openclaw qa credentials remove --credential-id
```
-Використовуйте `doctor` перед живими запусками, щоб перевірити URL сайту Convex, секрети брокера,
-префікс кінцевої точки, тайм-аут HTTP і доступність admin/list без виведення
-секретних значень. Використовуйте `--json` для машинозчитуваного виводу в скриптах і CI
+Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайту Convex, секрети брокера,
+префікс endpoint, HTTP-тайм-аут і доступність admin/list без виведення
+значень секретів. Використовуйте `--json` для машинозчитуваного виводу в скриптах та CI
утилітах.
-Контракт кінцевої точки за замовчуванням (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`):
+Стандартний контракт endpoint (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`):
- `POST /acquire`
- Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }`
@@ -393,66 +393,66 @@ pnpm openclaw qa credentials remove --credential-id
- Запит: `{ kind?, status?, includePayload?, limit? }`
- Успіх: `{ status: "ok", credentials, count }`
-Форма payload для виду Telegram:
+Форма payload для типу Telegram:
- `{ groupId: string, driverToken: string, sutToken: string }`
-- `groupId` має бути числовим рядком ідентифікатора чату Telegram.
+- `groupId` має бути рядком із числовим id чату Telegram.
- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє некоректні payload.
### Додавання каналу до QA
-Архітектура й назви помічників сценаріїв для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна планка: реалізувати transport runner на спільному шві хоста `qa-lab`, оголосити `qaRunners` у маніфесті plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`.
+Архітектура й назви scenario-helper для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна вимога: реалізуйте transport runner на спільному host seam `qa-lab`, оголосіть `qaRunners` у маніфесті Plugin, змонтуйте як `openclaw qa ` і створіть сценарії в `qa/scenarios/`.
## Набори тестів (що де запускається)
-Сприймайте набори як «зростання реалістичності» (і зростання нестабільності/вартості):
+Сприймайте набори як “зростання реалістичності” (і зростання нестабільності/вартості):
-### Модульні / інтеграційні (за замовчуванням)
+### Unit / integration (за замовчуванням)
- Команда: `pnpm test`
-- Конфіг: нецільові запуски використовують набір шард `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в поконфігураційні проєкти для паралельного планування
-- Файли: інвентарі ядра/модулів у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; модульні тести UI запускаються у виділеному шарді `unit-ui`
+- Конфіг: нецільові запуски використовують набір шардів `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в окремі конфіги проєктів для паралельного планування
+- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; unit-тести UI запускаються у виділеному шарді `unit-ui`
- Область:
- - Чисті модульні тести
- - Внутрішньопроцесні інтеграційні тести (автентифікація Gateway, маршрутизація, інструменти, розбір, конфіг)
- - Детерміновані регресії для відомих помилок
+ - Чисті unit-тести
+ - In-process integration-тести (автентифікація Gateway, маршрутизація, інструменти, парсинг, конфіг)
+ - Детерміновані регресії для відомих багів
- Очікування:
- Запускається в CI
- - Не потребує реальних ключів
+ - Реальні ключі не потрібні
- Має бути швидким і стабільним
- Тести резолвера й завантажувача публічної поверхні мають доводити широку fallback-поведінку `api.js` і
- `runtime-api.js` за допомогою згенерованих крихітних фікстур plugin, а не
- реальних API джерел вбудованих plugin. Реальні завантаження API plugin належать до
- контрактних/інтеграційних наборів, якими володіє plugin.
+ `runtime-api.js` згенерованими крихітними Plugin fixture, а не
+ реальними API вихідного коду bundled Plugin. Реальні завантаження API Plugin належать до
+ contract/integration-наборів, якими володіє Plugin.
- - Нецільовий `pnpm test` запускає дванадцять менших конфігів шард (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського нативного процесу кореневого проєкту. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension витісняти непов’язані набори.
- - `pnpm test --watch` і далі використовує нативний граф проєктів кореневого `vitest.config.ts`, бо цикл спостереження з багатьма шардами непрактичний.
- - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спершу маршрутизують явні цілі файлів/каталогів через scoped lanes, тож `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості старту кореневого проєкту.
- - `pnpm test:changed` за замовчуванням розгортає змінені git-шляхи в дешеві scoped lanes: прямі зміни тестів, сусідні файли `*.test.ts`, явні мапінги джерел і локальні залежні елементи графа імпортів. Зміни конфігів/setup/package не запускають широкі тести, якщо ви явно не використаєте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`.
- - `pnpm check:changed` — звичайний розумний локальний check gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata, live Docker tooling і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає тести Vitest; викликайте `pnpm test:changed` або явний `pnpm test ` для доказу тестами. Version bumps лише release metadata запускають цільові перевірки version/config/root-dependency із guard, який відхиляє зміни package поза верхньорівневим полем version.
- - Зміни live Docker ACP harness запускають фокусовані перевірки: синтаксис shell для скриптів live Docker auth і dry-run планувальника live Docker. Зміни `package.json` включаються лише коли diff обмежений `scripts["test:docker:live-*"]`; зміни dependency, export, version та іншої package-поверхні й далі використовують ширші guards.
- - Import-light модульні тести з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і подібних чистих utility-зон маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes.
- - Вибрані вихідні файли помічників `plugin-sdk` і `commands` також маплять changed-mode запуски на явні сусідні тести в цих легких lanes, тож зміни помічників не перезапускають увесь важкий набір для цього каталогу.
- - `auto-reply` має виділені bucket для верхньорівневих core helpers, верхньорівневих інтеграційних тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково ділить піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не забирав увесь хвіст Node.
- - Звичайний CI для PR/main навмисно пропускає пакетний sweep extensions і shard `agentic-plugins`, призначений лише для релізів. Full Release Validation запускає окремий дочірній workflow `Plugin Prerelease` для цих важких для plugin/extension наборів на release candidates.
+ - Нецільовий `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`) замість одного величезного native root-project процесу. Це зменшує піковий RSS на навантажених машинах і не дає auto-reply/extension роботі виснажувати непов’язані набори.
+ - `pnpm test --watch` і далі використовує native 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-шляхи в дешеві scoped lanes: прямі правки тестів, сусідні файли `*.test.ts`, явні мапінги source і локальні залежні вузли import-graph. Правки config/setup/package не запускають широкі тести, якщо ви явно не використаєте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`.
+ - `pnpm check:changed` є звичайним розумним локальним check gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata, live Docker tooling і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає тести Vitest; викликайте `pnpm test:changed` або явний `pnpm test ` для тестового доказу. Зміни версій лише в release metadata запускають цільові перевірки version/config/root-dependency із guard, який відхиляє package-зміни поза верхньорівневим полем version.
+ - Правки live Docker ACP harness запускають фокусовані перевірки: синтаксис shell для live Docker auth scripts і dry-run live Docker scheduler. Зміни `package.json` включаються лише тоді, коли diff обмежений `scripts["test:docker:live-*"]`; dependency, export, version та інші правки package-surface і далі використовують ширші guards.
+ - Import-light unit-тести з agents, commands, plugins, auto-reply helpers, `plugin-sdk` та подібних чистих utility-зон спрямовуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes.
+ - Вибрані helper source-файли `plugin-sdk` і `commands` також маплять changed-mode запуски на явні сусідні тести в цих light lanes, тож правки helper не перезапускають повний важкий набір для цієї директорії.
+ - `auto-reply` має виділені buckets для top-level core helpers, top-level integration-тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково розділяє піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не володів повним Node tail.
+ - Звичайний PR/main CI навмисно пропускає пакетний sweep extension і release-only шард `agentic-plugins`. Full Release Validation запускає окремий дочірній workflow `Plugin Prerelease` для цих важких plugin/extension-наборів на release candidates.
- - Коли ви змінюєте входи виявлення message-tool або runtime-контекст compaction,
- зберігайте обидва рівні покриття.
- - Додавайте сфокусовані регресії помічників для чистих меж маршрутизації та нормалізації.
- - Підтримуйте здоровими інтеграційні набори embedded runner:
+ - Коли ви змінюєте вхідні дані виявлення message-tool або runtime
+ context compaction, зберігайте обидва рівні покриття.
+ - Додайте фокусовані helper-регресії для меж чистої маршрутизації та нормалізації.
+ - Підтримуйте здоровими integration-набори embedded runner:
`src/agents/pi-embedded-runner/compact.hooks.test.ts`,
`src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` і
`src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`.
- Ці набори перевіряють, що scoped ids і поведінка compaction і далі проходять
- через реальні шляхи `run.ts` / `compact.ts`; тести лише помічників
- не є достатньою заміною для цих інтеграційних шляхів.
+ через реальні шляхи `run.ts` / `compact.ts`; helper-only тести не є
+ достатньою заміною цих integration-шляхів.
@@ -460,66 +460,66 @@ pnpm openclaw qa credentials remove --credential-id
- Базовий конфіг Vitest за замовчуванням використовує `threads`.
- Спільний конфіг Vitest фіксує `isolate: false` і використовує
- неізольований runner у кореневих проєктах, e2e і live-конфігах.
- - Кореневий UI lane зберігає свій setup `jsdom` і optimizer, але також працює на
- спільному неізольованому runner.
- - Кожен shard `pnpm test` успадковує ті самі значення за замовчуванням `threads` + `isolate: false`
+ non-isolated runner у root projects, e2e і live configs.
+ - Root UI lane зберігає свій setup і optimizer `jsdom`, але також запускається на
+ спільному non-isolated runner.
+ - Кожен шард `pnpm test` успадковує ті самі стандартні значення `threads` + `isolate: false`
зі спільного конфіга Vitest.
- - `scripts/run-vitest.mjs` за замовчуванням додає `--no-maglev` для дочірніх процесів Node
- Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків.
- Задайте `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8.
+ - `scripts/run-vitest.mjs` за замовчуванням додає `--no-maglev` для дочірніх Node
+ процесів Vitest, щоб зменшити V8 compile churn під час великих локальних запусків.
+ Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8.
- `pnpm changed:lanes` показує, які архітектурні lanes запускає diff.
- - Pre-commit hook виконує лише форматування. Він повторно додає відформатовані файли до staging і
+ - Pre-commit hook виконує лише форматування. Він повторно stage-ить відформатовані файли й
не запускає lint, typecheck або тести.
- - Запускайте `pnpm check:changed` явно перед передаванням роботи або push, коли вам
- потрібен розумний локальний check gate.
- - `pnpm test:changed` за замовчуванням маршрутизується через дешеві scoped lanes. Використовуйте
- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли агент
- вирішує, що редагування harness, config, package або contract справді потребує ширшого
+ - Запускайте `pnpm check:changed` явно перед handoff або push, коли вам
+ потрібен smart local check gate.
+ - `pnpm test:changed` за замовчуванням проходить через дешеві scoped lanes. Використовуйте
+ `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли агент
+ вирішує, що правка harness, config, package або contract справді потребує ширшого
покриття Vitest.
- `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації,
- лише з вищим лімітом workers.
- - Автомасштабування локальних workers навмисно консервативне й відступає,
- коли load average хоста вже високий, тож кілька одночасних
+ лише з вищим лімітом worker.
+ - Автомасштабування локальних worker навмисно консервативне й відступає,
+ коли середнє навантаження host уже високе, тож кілька паралельних
запусків Vitest за замовчуванням завдають менше шкоди.
- - Базовий конфіг Vitest позначає проєкти/конфігураційні файли як
- `forceRerunTriggers`, щоб повторні запуски changed-mode залишалися правильними, коли змінюється
- обв’язка тестів.
+ - Базовий конфіг Vitest позначає проєкти/config files як
+ `forceRerunTriggers`, щоб changed-mode перезапуски залишалися коректними, коли змінюється
+ test wiring.
- Конфіг залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних
- хостах; задайте `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете
- одну явну локацію cache для прямого профілювання.
+ hosts; задайте `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете
+ одну явну cache location для прямого profiling.
- - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпортів плюс
- вивід import-breakdown.
- - `pnpm test:perf:imports:changed` обмежує той самий перегляд профілювання
- файлами, зміненими з `origin/main`.
- - Дані часу shard записуються в `.artifacts/vitest-shard-timings.json`.
- Запуски whole-config використовують шлях конфіга як ключ; include-pattern CI
- shards додають назву shard, щоб відфільтровані shards можна було відстежувати
+ - `pnpm test:perf:imports` вмикає звітування Vitest про import-duration плюс
+ import-breakdown output.
+ - `pnpm test:perf:imports:changed` обмежує той самий profiling view
+ файлами, зміненими відносно `origin/main`.
+ - Дані shard timing записуються в `.artifacts/vitest-shard-timings.json`.
+ Whole-config запуски використовують шлях config як key; include-pattern CI
+ shards додають назву shard, щоб filtered shards можна було відстежувати
окремо.
- - Коли один hot test усе ще витрачає більшість часу на startup imports,
- тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і
- mock цей шов напряму замість deep-import runtime helpers лише
- щоб передати їх через `vi.mock(...)`.
- - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований
- `test:changed` із нативним шляхом root-project для цього закоміченого
- diff і друкує wall time плюс max RSS на macOS.
- - `pnpm test:perf:changed:bench -- --worktree` бенчмаркить поточне
- dirty tree, маршрутизуючи список змінених файлів через
- `scripts/test-projects.mjs` і кореневий конфіг Vitest.
- - `pnpm test:perf:profile:main` записує CPU profile головного потоку для
- накладних витрат запуску й трансформацій Vitest/Vite.
+ - Коли один hot test і далі витрачає більшість часу на startup imports,
+ тримайте важкі залежності за вузьким локальним seam `*.runtime.ts` і
+ мокайте цей seam напряму, замість deep-importing runtime helpers лише
+ для передавання їх через `vi.mock(...)`.
+ - `pnpm test:perf:changed:bench -- --ref ` порівнює routed
+ `test:changed` із native root-project path для цього committed
+ diff і виводить wall time плюс macOS max RSS.
+ - `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного
+ dirty tree, спрямовуючи список змінених файлів через
+ `scripts/test-projects.mjs` і root конфіг Vitest.
+ - `pnpm test:perf:profile:main` записує CPU profile main-thread для
+ startup Vitest/Vite і transform overhead.
- `pnpm test:perf:profile:runner` записує CPU+heap profiles runner для
- unit suite з вимкненим файловим паралелізмом.
+ unit suite з вимкненим file parallelism.
@@ -529,256 +529,256 @@ pnpm openclaw qa credentials remove --credential-id
- Команда: `pnpm test:stability:gateway`
- Конфіг: `vitest.gateway.config.ts`, примусово один worker
- Область:
- - Запускає реальний loopback Gateway із діагностикою, увімкненою за замовчуванням
- - Проганяє синтетичні Gateway message, memory і large-payload churn через шлях діагностичних подій
+ - Запускає реальний loopback Gateway із diagnostics, увімкненими за замовчуванням
+ - Проганяє synthetic gateway message, memory і large-payload churn через diagnostic event path
- Запитує `diagnostics.stability` через Gateway WS RPC
- - Покриває помічники збереження diagnostic stability bundle
- - Перевіряє, що recorder залишається обмеженим, синтетичні RSS samples залишаються нижче pressure budget, а глибини per-session queue повертаються до нуля
+ - Покриває diagnostic stability bundle persistence helpers
+ - Перевіряє, що recorder залишається обмеженим, synthetic RSS samples лишаються нижче pressure budget, а per-session queue depths повертаються до нуля
- Очікування:
- Безпечно для CI і без ключів
- - Вузький lane для follow-up регресій стабільності, а не заміна повного набору Gateway
+ - Вузький lane для stability-regression follow-up, не заміна повного Gateway suite
-### E2E (Gateway smoke)
+### E2E (gateway smoke)
- Команда: `pnpm test:e2e`
-- Конфігурація: `vitest.e2e.config.ts`
-- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled-plugin у `extensions/`
-- Типові параметри виконання:
- - Використовує Vitest `threads` з `isolate: false`, відповідно до решти репозиторію.
- - Використовує адаптивні workers (CI: до 2, локально: типово 1).
- - Типово запускається в тихому режимі, щоб зменшити накладні витрати консольного I/O.
+- Конфіг: `vitest.e2e.config.ts`
+- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести вбудованих Plugin у `extensions/`
+- Типові налаштування середовища виконання:
+ - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію.
+ - Використовує адаптивні воркери (CI: до 2, локально: типово 1).
+ - Типово запускається в тихому режимі, щоб зменшити накладні витрати console I/O.
- Корисні перевизначення:
- - `OPENCLAW_E2E_WORKERS=` для примусового задання кількості workers (обмежено 16).
- - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення докладного консольного виводу.
-- Область:
- - Наскрізна поведінка багатоекземплярного Gateway
- - Поверхні WebSocket/HTTP, спарювання вузлів і важча мережева взаємодія
+ - `OPENCLAW_E2E_WORKERS=` для примусового встановлення кількості воркерів (обмежено 16).
+ - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення докладного виводу в консоль.
+- Обсяг:
+ - End-to-end поведінка Gateway з кількома екземплярами
+ - Поверхні WebSocket/HTTP, сполучення Node і важчі мережеві сценарії
- Очікування:
- - Запускається в CI (коли ввімкнено в pipeline)
+ - Запускається в CI (коли ввімкнено в пайплайні)
- Реальні ключі не потрібні
- - Більше рухомих частин, ніж у модульних тестах (може бути повільніше)
+ - Більше рухомих частин, ніж у unit-тестах (може бути повільніше)
-### E2E: smoke-тест бекенду OpenShell
+### E2E: димовий тест бекенда OpenShell
- Команда: `pnpm test:e2e:openshell`
- Файл: `extensions/openshell/src/backend.e2e.test.ts`
-- Область:
+- Обсяг:
- Запускає ізольований OpenShell Gateway на хості через Docker
- Створює sandbox із тимчасового локального Dockerfile
- - Перевіряє бекенд OpenShell в OpenClaw через справжні `sandbox ssh-config` + SSH exec
+ - Перевіряє бекенд OpenShell в OpenClaw через реальні `sandbox ssh-config` + виконання SSH
- Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge
- Очікування:
- Лише opt-in; не входить до типового запуску `pnpm test:e2e`
- - Потребує локального `openshell` CLI та робочого Docker daemon
+ - Потребує локального CLI `openshell` і робочого Docker daemon
- Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий Gateway і sandbox
- Корисні перевизначення:
- `OPENCLAW_E2E_OPENSHELL=1` для ввімкнення тесту під час ручного запуску ширшого e2e-набору
- - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` для вказання нестандартного CLI-бінарника або wrapper-скрипта
+ - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` для вказання нестандартного CLI-бінарника або wrapper script
-### Живі (реальні провайдери + реальні моделі)
+### Live (реальні провайдери + реальні моделі)
- Команда: `pnpm test:live`
-- Конфігурація: `vitest.live.config.ts`
-- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і живі тести bundled-plugin у `extensions/`
+- Конфіг: `vitest.live.config.ts`
+- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести вбудованих Plugin у `extensions/`
- Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`)
-- Область:
- - “Чи цей провайдер/модель справді працює _сьогодні_ зі справжніми обліковими даними?”
- - Виявлення змін форматів провайдерів, особливостей tool-calling, проблем автентифікації та поведінки rate limit
+- Обсяг:
+ - “Чи цей провайдер/модель справді працює _сьогодні_ з реальними обліковими даними?”
+ - Виявлення змін формату провайдера, особливостей виклику інструментів, проблем автентифікації та поведінки rate limit
- Очікування:
- За задумом не є стабільним для CI (реальні мережі, реальні політики провайдерів, квоти, збої)
- Коштує грошей / використовує rate limits
- Надавайте перевагу запуску звужених піднаборів замість “усього”
-- Живі запуски підвантажують `~/.profile`, щоб отримати відсутні API-ключі.
-- Типово живі запуски все одно ізолюють `HOME` і копіюють матеріали config/auth у тимчасовий тестовий home, щоб модульні fixtures не могли змінити ваш справжній `~/.openclaw`.
-- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли навмисно потрібно, щоб живі тести використовували ваш справжній домашній каталог.
-- `pnpm test:live` тепер типово працює в тихішому режимі: він зберігає progress-вивід `[live] ...`, але приглушує додаткове повідомлення `~/.profile` і вимикає журнали bootstrap Gateway/шум Bonjour. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні startup-журнали.
-- Ротація API-ключів (специфічна для провайдера): задайте `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або перевизначення для live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях rate limit.
+- Live-запуски підвантажують `~/.profile`, щоб отримати відсутні API-ключі.
+- Типово live-запуски все ще ізолюють `HOME` і копіюють конфігурацію/автентифікаційні матеріали в тимчасову тестову домашню директорію, щоб unit-фікстури не могли змінити ваш реальний `~/.openclaw`.
+- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли навмисно потрібно, щоб live-тести використовували вашу реальну домашню директорію.
+- `pnpm test:live` тепер типово працює в тихішому режимі: він зберігає прогрес-вивід `[live] ...`, але приглушує додаткове повідомлення `~/.profile` і вимикає логи bootstrap Gateway/Bonjour chatter. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні стартові логи.
+- Ротація API-ключів (залежно від провайдера): встановіть `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або per-live перевизначення через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях rate limit.
- Вивід прогресу/Heartbeat:
- - Живі набори тепер виводять рядки прогресу в stderr, тож тривалі виклики провайдерів помітно активні навіть коли захоплення консолі Vitest тихе.
- - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб рядки прогресу провайдера/Gateway транслювалися одразу під час живих запусків.
- - Налаштовуйте Heartbeat для direct-model через `OPENCLAW_LIVE_HEARTBEAT_MS`.
- - Налаштовуйте Heartbeat для gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`.
+ - Live-набори тепер виводять рядки прогресу в stderr, тож довгі виклики провайдерів видимо активні навіть коли захоплення консолі Vitest тихе.
+ - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб рядки прогресу провайдера/Gateway одразу транслювалися під час live-запусків.
+ - Налаштовуйте direct-model Heartbeat через `OPENCLAW_LIVE_HEARTBEAT_MS`.
+ - Налаштовуйте Heartbeat для Gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`.
-## Який набір слід запускати?
+## Який набір мені запускати?
-Використовуйте цю таблицю рішень:
+Скористайтеся цією таблицею рішень:
-- Редагування логіки/тестів: запустіть `pnpm test` (і `pnpm test:coverage`, якщо ви змінили багато)
-- Зміна мережевої взаємодії Gateway / WS-протоколу / спарювання: додайте `pnpm test:e2e`
-- Налагодження “мій бот не працює” / специфічних для провайдера збоїв / tool calling: запустіть звужений `pnpm test:live`
+- Редагування логіки/тестів: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато)
+- Зміни мережевої частини Gateway / протоколу WS / сполучення: додайте `pnpm test:e2e`
+- Налагодження “мій бот не працює” / провайдер-специфічних збоїв / виклику інструментів: запускайте звужений `pnpm test:live`
-## Живі (мережеві) тести
+## Live (мережеві) тести
-Для live model matrix, smoke-тестів CLI-бекенду, smoke-тестів ACP, harness app-server Codex
-і всіх живих тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, image,
-music, video, media harness), а також обробки облікових даних для живих запусків, див.
-[Тестування живих наборів](/uk/help/testing-live). Для спеціального checklist перевірки оновлень і
-Plugin див.
-[Тестування оновлень і plugins](/uk/help/testing-updates-plugins).
+Для live-матриці моделей, димових тестів CLI-бекенда, димових тестів ACP, harness сервера застосунку Codex
+і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, зображення,
+музика, відео, media harness) — а також обробки облікових даних для live-запусків — див.
+[Тестування live-наборів](/uk/help/testing-live). Для спеціального чекліста оновлень і
+перевірки Plugin див.
+[Тестування оновлень і Plugin](/uk/help/testing-updates-plugins).
## Docker runners (необов’язкові перевірки "працює в Linux")
Ці Docker runners поділяються на дві групи:
-- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл profile-key усередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний config dir і workspace (і підвантажують `~/.profile`, якщо змонтовано). Відповідні локальні entrypoints: `test:live:models-profiles` і `test:live:gateway-profiles`.
-- Docker live runners типово мають меншу smoke-стелю, щоб повний Docker sweep залишався практичним:
- `test:docker:live-models` типово задає `OPENCLAW_LIVE_MAX_MODELS=12`, а
- `test:docker:live-gateway` типово задає `OPENCLAW_LIVE_GATEWAY_SMOKE=1`,
+- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл profile-key всередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують вашу локальну директорію конфігурації та робочу область (і підвантажують `~/.profile`, якщо змонтовано). Відповідні локальні entrypoints: `test:live:models-profiles` і `test:live:gateway-profiles`.
+- Docker live runners типово мають менший smoke-ліміт, щоб повний Docker sweep лишався практичним:
+ `test:docker:live-models` типово встановлює `OPENCLAW_LIVE_MAX_MODELS=12`, а
+ `test:docker:live-gateway` типово встановлює `OPENCLAW_LIVE_GATEWAY_SMOKE=1`,
`OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`,
`OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` і
- `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли
+ `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли ви
явно хочете більший вичерпний scan.
-- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Bare image є лише Node/Git runner для install/update/plugin-dependency lanes; ці lanes монтують попередньо зібраний tarball. Functional image встановлює той самий tarball у `/app` для built-app functionality lanes. Визначення Docker lanes розміщені в `scripts/lib/docker-e2e-scenarios.mjs`; логіка planner розміщена в `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний plan. Агрегат використовує weighted local scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує process slots, тоді як resource caps не дають heavy live, npm-install і multi-service lanes стартувати всім одночасно. Якщо окремий lane важчий за активні caps, scheduler усе ще може запустити його, коли pool порожній, а потім тримати його запущеним наодинці, доки знову не стане доступна capacity. Типові значення: 10 slots, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker host має більше запасу. Runner типово виконує Docker preflight, видаляє застарілі OpenClaw E2E containers, друкує статус кожні 30 секунд, зберігає timings успішних lanes у `.artifacts/docker-tests/lane-timings.json` і використовує ці timings, щоб у наступних запусках спочатку стартували довші lanes. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати weighted lane manifest без збирання чи запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI plan для вибраних lanes, потреб package/image і облікових даних.
-- `Package Acceptance` — це GitHub-native package gate для "чи цей installable tarball працює як продукт?" Він визначає один candidate package з `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає reusable Docker E2E lanes проти саме цього tarball замість повторного пакування вибраного ref. Профілі впорядковані за широтою: `smoke`, `package`, `product` і `full`. Див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins) щодо контракту package/update/plugin, published-upgrade survivor matrix, типових параметрів release і triage збоїв.
-- Перевірки build і release запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Guard проходить статичний built graph від `dist/entry.js` і `dist/cli/run-main.js` і завершується помилкою, якщо pre-dispatch startup імпортує package dependencies на кшталт Commander, prompt UI, undici або logging до command dispatch; він також утримує bundled gateway run chunk у межах бюджету та відхиляє статичні імпорти відомих cold gateway paths. Packaged CLI smoke також покриває root help, onboard help, doctor help, status, config schema і команду model-list.
-- Застаріла сумісність Package Acceptance обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цієї межі harness допускає лише прогалини shipped-package metadata: пропущені private QA inventory entries, відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git fixture, відсутній persisted `update.channel`, legacy plugin install-record locations, відсутня marketplace install-record persistence і config metadata migration під час `plugins update`. Для пакетів після `2026.4.25` ці шляхи є strict failures.
-- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:published-upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update`, `test:docker:plugin-lifecycle-matrix` і `test:docker:config-reload` запускають один або більше реальних containers і перевіряють інтеграційні шляхи вищого рівня.
+- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Bare image є лише Node/Git runner для install/update/plugin-dependency lanes; ці lanes монтують попередньо зібраний tarball. Functional image встановлює той самий tarball у `/app` для built-app functionality lanes. Визначення Docker lane містяться в `scripts/lib/docker-e2e-scenarios.mjs`; логіка planner міститься в `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний plan. Агрегат використовує зважений локальний scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує process slots, а resource caps не дають важким live, npm-install і multi-service lanes стартувати одночасно. Якщо окрема lane важча за активні caps, scheduler усе ще може запустити її, коли pool порожній, а потім тримає її самостійно, доки знову не буде доступна ємність. Типові значення: 10 slots, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише коли Docker host має більше запасу. Runner типово виконує Docker preflight, видаляє застарілі OpenClaw E2E containers, друкує статус кожні 30 секунд, зберігає timings успішних lanes у `.artifacts/docker-tests/lane-timings.json` і використовує ці timings, щоб у наступних запусках спершу стартували довші lanes. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати weighted lane manifest без збирання або запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI plan для вибраних lanes, потреб package/image та облікових даних.
+- `Package Acceptance` — це GitHub-native package gate для "чи цей installable tarball працює як продукт?" Він визначає один candidate package із `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає reusable Docker E2E lanes проти саме цього tarball замість повторного пакування вибраного ref. Профілі впорядковані за широтою: `smoke`, `package`, `product` і `full`. Див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins) щодо package/update/plugin contract, матриці published-upgrade survivor, release defaults і triage збоїв.
+- Перевірки build і release запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Guard обходить static built graph від `dist/entry.js` і `dist/cli/run-main.js` і завершується з помилкою, якщо pre-dispatch startup імпортує package dependencies, як-от Commander, prompt UI, undici або logging, до dispatch команди; він також утримує bundled gateway run chunk у межах бюджету і відхиляє static imports відомих cold gateway paths. Packaged CLI smoke також охоплює root help, onboard help, doctor help, status, config schema і команду model-list.
+- Legacy-сумісність Package Acceptance обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цього cutoff harness допускає лише прогалини metadata shipped-package: пропущені private QA inventory entries, відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git fixture, відсутній persisted `update.channel`, застарілі plugin install-record locations, відсутня marketplace install-record persistence і міграція config metadata під час `plugins update`. Для пакетів після `2026.4.25` ці paths є строгими помилками.
+- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:published-upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update`, `test:docker:plugin-lifecycle-matrix` і `test:docker:config-reload` запускають один або кілька реальних containers і перевіряють інтеграційні paths вищого рівня.
-Live-model Docker runners також bind-mount лише потрібні CLI auth homes (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у container home перед запуском, щоб external-CLI OAuth міг оновлювати tokens, не змінюючи auth store хоста:
+Live-model Docker runners також bind-mount лише потрібні CLI auth homes (або всі підтримувані, коли запуск не звужений), а потім копіюють їх у домашню директорію контейнера перед запуском, щоб external-CLI OAuth міг оновлювати tokens без зміни auth store хоста:
- Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`)
-- Smoke-тест прив’язування ACP: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; типово охоплює Claude, Codex і Gemini, зі строгим покриттям Droid/OpenCode через `pnpm test:docker:live-acp-bind:droid` і `pnpm test:docker:live-acp-bind:opencode`)
-- Smoke-тест бекенда CLI: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`)
-- Smoke-тест обв’язки сервера застосунку Codex: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`)
-- Gateway + dev-агент: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`)
-- Smoke-тест спостережуваності: `pnpm qa:otel:smoke` — це приватна QA-гілка перевірки з checkout вихідного коду. Її навмисно не включено до Docker-гілок випуску пакета, бо npm-тарбол не містить QA Lab.
-- Живий smoke-тест Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`)
-- Майстер онбордингу (TTY, повне створення каркаса): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`)
-- Smoke-тест онбордингу/каналу/агента з npm-тарбола: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований тарбол OpenClaw у Docker, налаштовує OpenAI через онбординг з посиланням на env, а також типово Telegram, запускає doctor і виконує один замоканий хід агента OpenAI. Повторно використовуйте попередньо зібраний тарбол із `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте перебудову на хості через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемикайте канал за допомогою `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`.
-- Smoke-тест перемикання каналу оновлень: `pnpm test:docker:update-channel-switch` глобально встановлює запакований тарбол OpenClaw у Docker, перемикається з пакетного `stable` на git `dev`, перевіряє збережений канал і роботу plugin після оновлення, потім перемикається назад на пакетний `stable` і перевіряє статус оновлення.
-- Smoke-тест стійкості після оновлення: `pnpm test:docker:upgrade-survivor` встановлює запакований тарбол OpenClaw поверх забрудненого фікстура старого користувача з агентами, конфігурацією каналів, allowlist-ами plugin, застарілим станом залежностей plugin і наявними файлами робочої області/сесії. Він запускає оновлення пакета плюс неінтерактивний doctor без живого провайдера або ключів каналу, потім стартує loopback Gateway і перевіряє збереження конфігурації/стану, а також бюджети запуску/статусу.
-- Smoke-тест стійкості після оновлення з опублікованої версії: `pnpm test:docker:published-upgrade-survivor` типово встановлює `openclaw@latest`, засіває реалістичні файли наявного користувача, налаштовує цей базовий стан вбудованим рецептом команд, перевіряє отриману конфігурацію, оновлює це опубліковане встановлення до кандидатного тарбола, запускає неінтерактивний doctor, записує `.artifacts/upgrade-survivor/summary.json`, потім стартує loopback Gateway і перевіряє налаштовані intents, збереження стану, запуск, `/healthz`, `/readyz` і бюджети RPC-статусу. Перевизначте один базовий стан через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, попросіть агрегований планувальник розгорнути точні базові стани через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, наприклад `all-since-2026.4.23`, і розгорніть фікстури у формі issue через `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS`, наприклад `reported-issues`; набір reported-issues містить `configured-plugin-installs` для автоматичного відновлення встановлення зовнішніх OpenClaw plugin. Package Acceptance показує їх як `published_upgrade_survivor_baseline`, `published_upgrade_survivor_baselines` і `published_upgrade_survivor_scenarios`; Full Release Validation використовує типовий latest-базовий стан у блокувальному шляху та розгортає до all-since/reported-issues лише для `run_release_soak=true` або `release_profile=full`.
-- Smoke-тест runtime-контексту сесії: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого runtime-контексту в транскрипті плюс repair через doctor для уражених дубльованих гілок prompt-rewrite.
-- Smoke-тест глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих провайдерів зображень, а не зависає. Повторно використовуйте попередньо зібраний тарбол із `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте збірку на хості через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або копіюйте `dist/` зі зібраного Docker-образу через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`.
-- Docker-smoke інсталятора: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm-кеш між своїми root-, update- і direct-npm-контейнерами. Smoke-тест оновлення типово використовує npm `latest` як stable-базу перед оновленням до кандидатного тарбола. Перевизначте локально через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через input `update_baseline_version` у workflow Install Smoke на GitHub. Перевірки інсталятора без root зберігають ізольований npm-кеш, щоб записи кешу, власником яких є root, не маскували поведінку користувацького локального встановлення. Задайте `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати кеш root/update/direct-npm між локальними перезапусками.
-- Install Smoke CI пропускає дубльоване глобальне оновлення direct-npm через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`.
-- Smoke-тест CLI видалення агентами спільної робочої області: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) типово збирає образ кореневого Dockerfile, засіває двох агентів з однією робочою областю в ізольованому container home, запускає `agents delete --json` і перевіряє валідний JSON плюс поведінку збереженої робочої області. Повторно використовуйте install-smoke-образ через `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`.
+- Димовий тест прив’язки ACP: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; за замовчуванням охоплює Claude, Codex і Gemini, зі строгим покриттям Droid/OpenCode через `pnpm test:docker:live-acp-bind:droid` і `pnpm test:docker:live-acp-bind:opencode`)
+- Димовий тест бекенду CLI: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`)
+- Димовий тест обв’язки сервера застосунку Codex: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`)
+- Gateway + агент розробки: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`)
+- Димовий тест спостережуваності: `pnpm qa:otel:smoke` — це приватна QA-смуга для перевірки checkout із вихідного коду. Її навмисно не включено до Docker-смуг релізу пакета, оскільки npm-архів не містить QA Lab.
+- Димовий тест Open WebUI наживо: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`)
+- Майстер онбордингу (TTY, повне риштування): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`)
+- Димовий тест онбордингу/каналу/агента для npm-архіву: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований архів OpenClaw у Docker, налаштовує OpenAI через онбординг із посиланням на змінну середовища та Telegram за замовчуванням, запускає doctor і виконує один змокований хід агента OpenAI. Повторно використовуйте попередньо зібраний архів за допомогою `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте перебудову на хості через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемикайте канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord` чи `OPENCLAW_NPM_ONBOARD_CHANNEL=slack`.
+- Димовий тест перемикання каналу оновлень: `pnpm test:docker:update-channel-switch` глобально встановлює запакований архів OpenClaw у Docker, перемикає з пакета `stable` на git `dev`, перевіряє збережений канал і роботу Plugin після оновлення, потім перемикає назад на пакет `stable` і перевіряє статус оновлення.
+- Димовий тест виживання після оновлення: `pnpm test:docker:upgrade-survivor` встановлює запакований архів OpenClaw поверх забрудненого фікстура старого користувача з агентами, конфігурацією каналу, allowlist Plugin, застарілим станом залежностей Plugin і наявними файлами робочого простору/сесій. Він запускає оновлення пакета й неінтерактивний doctor без live-ключів провайдера або каналу, потім запускає loopback Gateway і перевіряє збереження конфігурації/стану та бюджети запуску/статусу.
+- Димовий тест виживання після оновлення опублікованої версії: `pnpm test:docker:published-upgrade-survivor` за замовчуванням встановлює `openclaw@latest`, засіває реалістичні файли наявного користувача, налаштовує цю базову версію за вбудованим рецептом команд, перевіряє отриману конфігурацію, оновлює цю опубліковану інсталяцію до кандидатного архіву, запускає неінтерактивний doctor, записує `.artifacts/upgrade-survivor/summary.json`, потім запускає loopback Gateway і перевіряє налаштовані наміри, збереження стану, запуск, `/healthz`, `/readyz` і бюджети статусу RPC. Перевизначте одну базову версію через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, попросіть агрегований планувальник розгорнути точні базові версії через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, наприклад `all-since-2026.4.23`, і розгорніть фікстури у формі issue через `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS`, наприклад `reported-issues`; набір reported-issues містить `configured-plugin-installs` для автоматичного виправлення встановлення зовнішнього OpenClaw Plugin. Package Acceptance надає їх як `published_upgrade_survivor_baseline`, `published_upgrade_survivor_baselines` і `published_upgrade_survivor_scenarios`; Full Release Validation використовує стандартну базову версію latest у блокувальному шляху й розгортає до all-since/reported-issues лише для `run_release_soak=true` або `release_profile=full`.
+- Димовий тест runtime-контексту сесії: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого runtime-контексту в транскрипті та repair від doctor для зачеплених дубльованих гілок переписування prompt.
+- Димовий тест глобального встановлення 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: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm-кеш для своїх root-, update- і direct-npm-контейнерів. Димовий тест оновлення за замовчуванням використовує npm `latest` як стабільну базу перед оновленням до кандидатного архіву. Перевизначте через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` локально або через вхід `update_baseline_version` workflow Install Smoke на GitHub. Перевірки інсталятора без root зберігають ізольований npm-кеш, щоб записи кешу, власником яких є root, не приховували поведінку встановлення в локальному просторі користувача. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати кеш root/update/direct-npm між локальними повторними запусками.
+- Install Smoke CI пропускає дубльоване пряме глобальне оновлення npm через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цієї змінної середовища, коли потрібне покриття прямого `npm install -g`.
+- Димовий тест CLI видалення агентами спільного робочого простору: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає образ root Dockerfile, засіває двох агентів з одним робочим простором в ізольованому домашньому каталозі контейнера, запускає `agents delete --json` і перевіряє валідний JSON та поведінку збереженого робочого простору. Повторно використовуйте образ install-smoke через `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`.
- Мережа Gateway (два контейнери, WS-автентифікація + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`)
-- Smoke-тест CDP-знімка браузера: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає вихідний E2E-образ плюс шар Chromium, запускає Chromium із сирим CDP, виконує `browser doctor --deep` і перевіряє, що CDP-знімки ролей охоплюють URL посилань, clickable-елементи, підвищені курсором, refs iframe і метадані frame.
-- Регресія мінімального reasoning для OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає замоканий сервер OpenAI через Gateway, перевіряє, що `web_search` піднімає `reasoning.effort` з `minimal` до `low`, потім примусово викликає відхилення схеми провайдером і перевіряє, що сирі подробиці з’являються в логах Gateway.
-- Міст каналу MCP (засіяний Gateway + stdio-міст + smoke-тест сирого notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`)
-- MCP-інструменти Pi bundle (реальний stdio MCP-сервер + smoke-тест вбудованого Pi-профілю allow/deny): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`)
-- Очищення Cron/subagent MCP (реальний Gateway + завершення stdio MCP-дочірнього процесу після ізольованого cron і одноразових запусків subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`)
-- Plugins (smoke-тест встановлення/оновлення для локального шляху, `file:`, npm registry з hoisted-залежностями, рухомих git refs, ClawHub kitchen-sink, marketplace-оновлень і ввімкнення/інспекції Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`)
- Задайте `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте типову пару package/runtime для kitchen-sink через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний сервер фікстур ClawHub.
-- Smoke-тест незміненого оновлення plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`)
-- Smoke-тест матриці життєвого циклу Plugin: `pnpm test:docker:plugin-lifecycle-matrix` встановлює запакований тарбол OpenClaw у порожній контейнер, встановлює npm plugin, перемикає enable/disable, оновлює та понижує його версію через локальний npm registry, видаляє встановлений код, потім перевіряє, що uninstall усе ще прибирає застарілий стан, паралельно логуючи метрики RSS/CPU для кожної фази життєвого циклу.
-- Smoke-тест metadata reload конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`)
-- Plugins: `pnpm test:docker:plugins` охоплює smoke-тест встановлення/оновлення для локального шляху, `file:`, npm registry з hoisted-залежностями, рухомих git refs, фікстур ClawHub, marketplace-оновлень і ввімкнення/інспекції Claude-bundle. `pnpm test:docker:plugin-update` охоплює поведінку незміненого оновлення для встановлених plugins. `pnpm test:docker:plugin-lifecycle-matrix` охоплює встановлення, enable, disable, upgrade, downgrade і uninstall відсутнього коду для npm plugin з відстеженням ресурсів.
+- Димовий тест знімка Browser CDP: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає вихідний E2E-образ і шар Chromium, запускає Chromium із raw CDP, виконує `browser doctor --deep` і перевіряє, що знімки ролей 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-міст + димовий тест raw Claude notification-frame): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`)
+- MCP-інструменти Pi-бандла (реальний stdio MCP-сервер + димовий тест 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 (димовий тест встановлення/оновлення для локального шляху, `file:`, npm-реєстру з hoisted-залежностями, рухомих git-посилань, ClawHub kitchen-sink, оновлень marketplace і ввімкнення/інспектування Claude-бандла): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`)
+ Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте стандартну пару пакета/runtime kitchen-sink через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний фікстурний сервер ClawHub.
+- Димовий тест незмінного оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`)
+- Димовий тест матриці життєвого циклу Plugin: `pnpm test:docker:plugin-lifecycle-matrix` встановлює запакований архів OpenClaw у порожній контейнер, встановлює npm Plugin, перемикає ввімкнення/вимкнення, оновлює та понижує його через локальний npm-реєстр, видаляє встановлений код, а потім перевіряє, що uninstall усе ще прибирає застарілий стан, одночасно логуючи метрики RSS/CPU для кожної фази життєвого циклу.
+- Димовий тест метаданих перезавантаження конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`)
+- Plugins: `pnpm test:docker:plugins` охоплює димовий тест встановлення/оновлення для локального шляху, `file:`, npm-реєстру з hoisted-залежностями, рухомих git-посилань, фікстур ClawHub, оновлень marketplace і ввімкнення/інспектування Claude-бандла. `pnpm test:docker:plugin-update` охоплює поведінку незмінного оновлення для встановлених plugins. `pnpm test:docker:plugin-lifecycle-matrix` охоплює встановлення npm Plugin із відстеженням ресурсів, увімкнення, вимкнення, оновлення, пониження версії та uninstall за відсутнього коду.
-Щоб вручну попередньо зібрати та повторно використовувати спільний функціональний образ:
+Щоб вручну попередньо зібрати й повторно використовувати спільний функціональний образ:
```bash
OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker:e2e-build
OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels
```
-Перевизначення образів для окремих наборів, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти завантажують його, якщо він ще не локальний. Docker-тести QR та інсталятора зберігають власні Dockerfile, бо вони перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку.
+Специфічні для набору перевизначення образів, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли їх задано. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти завантажують його, якщо він ще не є локальним. QR- і Docker-тести інсталятора зберігають власні Dockerfile, оскільки вони перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку.
-Docker-ранери live-model також монтують поточний checkout лише для читання та
-розгортають його в тимчасовий робочий каталог усередині контейнера. Це зберігає
-runtime-образ компактним, але водночас запускає Vitest саме проти вашого локального source/config.
-Етап підготовки пропускає великі локальні кеші та вихідні дані збірки застосунків, як-от
-`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для застосунків каталоги `.build` або
-вихідні каталоги Gradle, щоб live-запуски Docker не витрачали хвилини на копіювання
-машинно-специфічних артефактів.
-Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-зонди Gateway не запускали
-реальні робочі процеси каналів Telegram/Discord/тощо всередині контейнера.
-`test:docker:live-models` усе ще запускає `pnpm test:live`, тому передавайте також
+Запускачі Docker з live-моделями також монтують поточний checkout лише для читання та
+розгортають його в тимчасовий робочий каталог усередині контейнера. Це зберігає runtime-образ
+компактним, водночас запускаючи Vitest саме з вашим локальним source/config.
+Крок розгортання пропускає великі локальні кеші та вихідні дані складання застосунків, як-от
+`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для застосунків `.build` або
+каталоги виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання
+артефактів, специфічних для машини.
+Вони також задають `OPENCLAW_SKIP_CHANNELS=1`, щоб live-перевірки Gateway не запускали
+реальні воркери каналів Telegram/Discord/тощо всередині контейнера.
+`test:docker:live-models` усе ще запускає `pnpm test:live`, тож також передавайте
`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити live-покриття Gateway
з цієї Docker-лінії.
-`test:docker:openwebui` — це суміснісний smoke вищого рівня: він запускає
-контейнер Gateway OpenClaw з увімкненими HTTP-ендпоінтами, сумісними з OpenAI,
-запускає закріплений контейнер Open WebUI проти цього Gateway, виконує вхід через
-Open WebUI, перевіряє, що `/api/models` exposes `openclaw/default`, а потім надсилає
-реальний запит чату через proxy `/api/chat/completions` Open WebUI.
-Перший запуск може бути помітно повільнішим, бо Docker може знадобитися завантажити
-образ Open WebUI, а Open WebUI може знадобитися завершити власне налаштування cold-start.
+`test:docker:openwebui` — це smoke-перевірка сумісності вищого рівня: вона запускає
+контейнер Gateway OpenClaw з увімкненими OpenAI-сумісними HTTP-ендпоїнтами,
+запускає закріплений контейнер Open WebUI проти цього Gateway, входить через
+Open WebUI, перевіряє, що `/api/models` відкриває `openclaw/default`, а потім надсилає
+реальний chat-запит через проксі `/api/chat/completions` Open WebUI.
+Перший запуск може бути помітно повільнішим, оскільки Docker може знадобитися отримати
+образ Open WebUI, а Open WebUI може знадобитися завершити власне налаштування холодного старту.
Ця лінія очікує придатний ключ live-моделі, а `OPENCLAW_PROFILE_FILE`
-(`~/.profile` за замовчуванням) є основним способом надати його в Dockerized-запусках.
-Успішні запуски друкують невелике JSON-навантаження на кшталт `{ "ok": true, "model":
+(`~/.profile` за замовчуванням) є основним способом надати його в Dockerизованих запусках.
+Успішні запуски друкують невеликий JSON payload на кшталт `{ "ok": true, "model":
"openclaw/default", ... }`.
`test:docker:mcp-channels` навмисно детермінований і не потребує
-реального облікового запису Telegram, Discord або iMessage. Він запускає контейнер Gateway
-із початковими даними, запускає другий контейнер, який породжує `openclaw mcp serve`, а потім
-перевіряє маршрутизоване виявлення розмов, читання транскриптів, метадані вкладень,
-поведінку live-черги подій, маршрутизацію вихідного надсилання та сповіщення каналу +
-дозволів у стилі Claude через справжній stdio MCP bridge. Перевірка сповіщень
-безпосередньо інспектує сирі stdio MCP frames, тож smoke перевіряє те, що
-bridge фактично emits, а не лише те, що випадково показує конкретний client SDK.
-`test:docker:pi-bundle-mcp-tools` детермінований і не потребує ключа live-моделі.
-Він збирає Docker-образ repo, запускає справжній stdio MCP probe server
-усередині контейнера, матеріалізує цей сервер через вбудований runtime MCP bundle Pi,
-виконує інструмент, а потім перевіряє, що `coding` і `messaging` зберігають
-інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують.
-`test:docker:cron-mcp-cleanup` детермінований і не потребує ключа live-моделі.
-Він запускає Gateway із початковими даними зі справжнім stdio MCP probe server, виконує
-ізольований cron-хід і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє,
-що дочірній процес MCP завершується після кожного запуску.
+реального облікового запису Telegram, Discord або iMessage. Він завантажує засіяний контейнер Gateway,
+запускає другий контейнер, який породжує `openclaw mcp serve`, а потім
+перевіряє маршрутизоване виявлення розмов, читання transcript, метадані вкладень,
+поведінку черги live-подій, маршрутизацію вихідного надсилання та Claude-style channel +
+сповіщення про дозволи через реальний stdio MCP bridge. Перевірка сповіщень
+інспектує сирі stdio MCP frames напряму, щоб smoke перевіряв те, що
+bridge фактично випромінює, а не лише те, що випадково показує конкретний client SDK.
+`test:docker:pi-bundle-mcp-tools` детермінований і не потребує live-ключа
+моделі. Він збирає Docker-образ репозиторію, запускає реальний stdio MCP probe server
+усередині контейнера, матеріалізує цей server через вбудований Pi bundle
+MCP runtime, виконує tool, а потім перевіряє, що `coding` і `messaging` зберігають
+tools `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують.
+`test:docker:cron-mcp-cleanup` детермінований і не потребує live-ключа моделі.
+Він запускає засіяний Gateway з реальним stdio MCP probe server, виконує
+ізольований cron turn і одноразовий child turn `/subagents spawn`, а потім перевіряє,
+що child-процес MCP завершується після кожного запуску.
-Ручний ACP smoke потоку простою мовою (не CI):
+Ручний ACP plain-language thread smoke (не CI):
- `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...`
-- Зберігайте цей скрипт для регресійних/debug workflows. Він може знову знадобитися для валідації маршрутизації потоків ACP, тому не видаляйте його.
+- Зберігайте цей script для workflow регресії/debug. Він може знову знадобитися для перевірки маршрутизації ACP thread, тому не видаляйте його.
-Корисні змінні середовища:
+Корисні env vars:
- `OPENCLAW_CONFIG_DIR=...` (за замовчуванням: `~/.openclaw`) монтується в `/home/node/.openclaw`
- `OPENCLAW_WORKSPACE_DIR=...` (за замовчуванням: `~/.openclaw/workspace`) монтується в `/home/node/.openclaw/workspace`
-- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) монтується в `/home/node/.profile` і завантажується перед запуском тестів
-- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` для перевірки лише змінних середовища, завантажених із `OPENCLAW_PROFILE_FILE`, з використанням тимчасових каталогів config/workspace і без зовнішніх монтувань auth CLI
-- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI усередині Docker
-- Зовнішні каталоги/файли auth CLI під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед запуском тестів
+- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) монтується в `/home/node/.profile` і source-иться перед запуском tests
+- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` для перевірки лише env vars, отриманих із `OPENCLAW_PROFILE_FILE`, з використанням тимчасових каталогів config/workspace і без зовнішніх монтувань CLI auth
+- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих установлень CLI всередині Docker
+- Зовнішні CLI auth dirs/files під `$HOME` монтуються лише для читання під `/host-auth...`, потім копіюються в `/home/node/...` перед стартом tests
- Каталоги за замовчуванням: `.minimax`
- Файли за замовчуванням: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json`
- - Звужені запуски provider монтують лише потрібні каталоги/файли, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS`
- - Перевизначайте вручну за допомогою `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або списку через кому на кшталт `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex`
+ - Звужені provider-запуски монтують лише потрібні dirs/files, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS`
+ - Перевизначте вручну через `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або comma list на кшталт `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex`
- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` для звуження запуску
- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` для фільтрації providers у контейнері
-- `OPENCLAW_SKIP_DOCKER_BUILD=1` для повторного використання наявного образу `openclaw:local-live` для повторних запусків, які не потребують перескладання
-- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` для гарантії, що облікові дані походять зі сховища профілю (не з env)
-- `OPENCLAW_OPENWEBUI_MODEL=...` для вибору моделі, яку Gateway exposes для smoke Open WebUI
-- `OPENCLAW_OPENWEBUI_PROMPT=...` для перевизначення nonce-check промпта, який використовує smoke Open WebUI
-- `OPENWEBUI_IMAGE=...` для перевизначення закріпленого тегу образу Open WebUI
+- `OPENCLAW_SKIP_DOCKER_BUILD=1` для повторного використання наявного образу `openclaw:local-live` у reruns, які не потребують повторного build
+- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб гарантувати, що creds надходять із profile store (а не env)
+- `OPENCLAW_OPENWEBUI_MODEL=...` для вибору моделі, яку Gateway відкриває для smoke Open WebUI
+- `OPENCLAW_OPENWEBUI_PROMPT=...` для перевизначення nonce-check prompt, що використовується smoke Open WebUI
+- `OPENWEBUI_IMAGE=...` для перевизначення закріпленого image tag Open WebUI
-## Санітарна перевірка docs
+## Перевірка документації
-Запускайте перевірки docs після редагувань docs: `pnpm check:docs`.
-Запускайте повну валідацію anchors Mintlify, коли потрібні також перевірки заголовків на сторінці: `pnpm docs:check-links:anchors`.
+Запускайте перевірки docs після редагувань документації: `pnpm check:docs`.
+Запускайте повну перевірку anchors Mintlify, коли також потрібні перевірки in-page headings: `pnpm docs:check-links:anchors`.
-## Офлайн-регресія (CI-safe)
+## Offline-регресія (CI-safe)
-Це регресії “реального pipeline” без реальних providers:
+Це регресії “real pipeline” без реальних providers:
-- Виклик інструментів Gateway (mock OpenAI, реальний gateway + agent loop): `src/gateway/gateway.test.ts` (case: "runs a mock OpenAI tool call end-to-end via gateway agent loop")
-- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує config + auth enforced): `src/gateway/gateway.test.ts` (case: "runs wizard over ws and writes auth token config")
+- Gateway tool calling (mock OpenAI, реальний gateway + agent loop): `src/gateway/gateway.test.ts` (case: "runs a mock OpenAI tool call end-to-end via gateway agent loop")
+- Gateway wizard (WS `wizard.start`/`wizard.next`, записує config + auth enforced): `src/gateway/gateway.test.ts` (case: "runs wizard over ws and writes auth token config")
-## Оцінювання надійності agent (skills)
+## Evals надійності agent (skills)
-У нас уже є кілька CI-safe тестів, які поводяться як “agent reliability evals”:
+У нас уже є кілька CI-safe tests, які поводяться як “agent reliability evals”:
- Mock tool-calling через реальний gateway + agent loop (`src/gateway/gateway.test.ts`).
-- End-to-end wizard flows, які перевіряють session wiring і наслідки config (`src/gateway/gateway.test.ts`).
+- End-to-end wizard flows, які перевіряють session wiring і config effects (`src/gateway/gateway.test.ts`).
Чого ще бракує для skills (див. [Skills](/uk/tools/skills)):
- **Decisioning:** коли skills перелічені в prompt, чи вибирає agent правильний skill (або уникає нерелевантних)?
-- **Compliance:** чи читає agent `SKILL.md` перед використанням і чи виконує required steps/args?
-- **Workflow contracts:** multi-turn сценарії, які перевіряють tool order, session history carryover і sandbox boundaries.
+- **Compliance:** чи читає agent `SKILL.md` перед використанням і чи дотримується required steps/args?
+- **Workflow contracts:** multi-turn scenarios, які перевіряють tool order, session history carryover і sandbox boundaries.
-Майбутні evals насамперед мають залишатися детермінованими:
+Майбутні evals мають насамперед залишатися детермінованими:
-- Scenario runner із mock providers для перевірки tool calls + order, читання skill file і session wiring.
-- Невеликий набір skill-focused scenarios (use vs avoid, gating, prompt injection).
-- Необов’язкові live evals (opt-in, env-gated) лише після появи CI-safe набору.
+- Scenario runner з mock providers для перевірки tool calls + order, читання skill file і session wiring.
+- Невеликий suite сценаріїв, сфокусованих на skills (use vs avoid, gating, prompt injection).
+- Необов’язкові live evals (opt-in, env-gated) лише після того, як CI-safe suite буде готовий.
-## Contract tests (форма Plugin і channel)
+## Contract tests (plugin і shape каналу)
-Contract tests перевіряють, що кожен зареєстрований Plugin і channel відповідає своєму
-interface contract. Вони проходять усі виявлені plugins і запускають набір
-shape and behavior assertions. Стандартна unit-лінія `pnpm test` навмисно
-пропускає ці shared seam і smoke файли; запускайте contract-команди явно,
-коли торкаєтеся shared channel або provider surfaces.
+Contract tests перевіряють, що кожен зареєстрований plugin і канал відповідає своєму
+interface contract. Вони проходять усі виявлені plugins і запускають suite
+перевірок shape і behavior. Стандартна unit-лінія `pnpm test` навмисно
+пропускає ці спільні seam і smoke files; запускайте contract-команди явно,
+коли торкаєтеся спільних поверхонь channel або provider.
### Команди
@@ -790,59 +790,59 @@ shape and behavior assertions. Стандартна unit-лінія `pnpm test`
Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`:
-- **plugin** - Базова форма Plugin (id, name, capabilities)
-- **setup** - Контракт майстра налаштування
-- **session-binding** - Поведінка прив’язки session
-- **outbound-payload** - Структура payload повідомлення
-- **inbound** - Обробка вхідних повідомлень
-- **actions** - Обробники дій channel
-- **threading** - Обробка thread ID
-- **directory** - API directory/roster
-- **group-policy** - Забезпечення group policy
+- **plugin** - Базовий shape plugin (id, name, capabilities)
+- **setup** - Contract setup wizard
+- **session-binding** - Поведінка session binding
+- **outbound-payload** - Структура message payload
+- **inbound** - Обробка inbound message
+- **actions** - Channel action handlers
+- **threading** - Обробка Thread ID
+- **directory** - Directory/roster API
+- **group-policy** - Застосування group policy
-### Контракти статусу provider
+### Provider status contracts
Розташовані в `src/plugins/contracts/*.contract.test.ts`.
-- **status** - Зонди статусу channel
-- **registry** - Форма registry Plugin
+- **status** - Channel status probes
+- **registry** - Shape Plugin registry
### Provider contracts
Розташовані в `src/plugins/contracts/*.contract.test.ts`:
-- **auth** - Контракт auth flow
-- **auth-choice** - Вибір/selection auth
-- **catalog** - API каталогу моделей
+- **auth** - Contract auth flow
+- **auth-choice** - Auth choice/selection
+- **catalog** - Model catalog API
- **discovery** - Виявлення Plugin
- **loader** - Завантаження Plugin
-- **runtime** - Runtime provider
-- **shape** - Форма/interface Plugin
-- **wizard** - Майстер налаштування
+- **runtime** - Provider runtime
+- **shape** - Shape/interface Plugin
+- **wizard** - Setup wizard
### Коли запускати
- Після зміни exports або subpaths plugin-sdk
-- Після додавання або зміни channel чи provider Plugin
-- Після рефакторингу реєстрації або discovery Plugin
+- Після додавання або модифікації channel чи provider plugin
+- Після рефакторингу plugin registration або discovery
Contract tests запускаються в CI і не потребують реальних API keys.
-## Додавання регресій (guidance)
+## Додавання регресій (настанови)
-Коли виправляєте issue provider/model, виявлену live:
+Коли ви виправляєте проблему provider/model, виявлену в live:
-- Додайте CI-safe regression, якщо можливо (mock/stub provider або зафіксуйте точне перетворення request-shape)
-- Якщо вона за своєю природою лише live-only (rate limits, auth policies), тримайте live test вузьким і opt-in через env vars
-- Надавайте перевагу найменшому шару, який ловить bug:
- - provider request conversion/replay bug → direct models test
- - gateway session/history/tool pipeline bug → gateway live smoke або CI-safe gateway mock test
+- Додайте CI-safe regression, якщо можливо (mock/stub provider або зафіксуйте точну request-shape transformation)
+- Якщо вона за своєю суттю лише live-only (rate limits, auth policies), тримайте live test вузьким і opt-in через env vars
+- Надавайте перевагу таргетуванню найменшого шару, який ловить bug:
+ - bug перетворення/відтворення provider request → direct models test
+ - bug gateway session/history/tool pipeline → gateway live smoke або CI-safe gateway mock test
- Guardrail обходу SecretRef:
- - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить один вибірковий target для кожного класу SecretRef із registry metadata (`listSecretTargetRegistryEntries()`), а потім asserts, що traversal-segment exec ids відхиляються.
- - Якщо додаєте нову target family SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на unclassified target ids, щоб нові classes не можна було тихо пропустити.
+ - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну sampled target для кожного класу SecretRef з registry metadata (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec ids із traversal-segment відхиляються.
+ - Якщо ви додаєте нову target family SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому test. Test навмисно падає на некласифікованих target ids, щоб нові classes не можна було мовчки пропустити.
## Пов’язане
-- [Тестування live](/uk/help/testing-live)
-- [Тестування оновлень і plugins](/uk/help/testing-updates-plugins)
+- [Testing live](/uk/help/testing-live)
+- [Testing updates and plugins](/uk/help/testing-updates-plugins)
- [CI](/uk/ci)