diff --git a/docs/uk/help/testing-live.md b/docs/uk/help/testing-live.md index aa112ad56..84331c94b 100644 --- a/docs/uk/help/testing-live.md +++ b/docs/uk/help/testing-live.md @@ -1,35 +1,35 @@ --- read_when: - - Запуск smoke-тестів живої матриці моделей / бекенду CLI / ACP / провайдера медіа + - Запуск перевірок smoke для живої матриці моделей / бекенду CLI / ACP / медіапровайдера - Налагодження визначення облікових даних для живих тестів - Додавання нового живого тесту, специфічного для провайдера sidebarTitle: Live tests -summary: 'Живі (мережеві) тести: матриця моделей, бекенди CLI, ACP, провайдери медіа, облікові дані' +summary: 'Живі (із зверненням до мережі) тести: матриця моделей, бекенди CLI, ACP, медіапровайдери, облікові дані' title: 'Тестування: живі набори тестів' x-i18n: - generated_at: "2026-04-25T10:05:02Z" + generated_at: "2026-04-25T12:43:16Z" model: gpt-5.4 provider: openai - source_hash: 4c91bfba6853db576e120893b8c2a55f9d396d523ad5b5eb6a25829766ee477f + source_hash: b9b2c2954eddd1b911dde5bb3a834a6f9429c91429f3fb07a509eec80183cc52 source_path: help/testing-live.md workflow: 15 --- -Для швидкого старту, раннерів QA, модульних/інтеграційних наборів і Docker-процесів див. -[Тестування](/uk/help/testing). На цій сторінці описано **живі** (мережеві) набори тестів: -матрицю моделей, бекенди CLI, ACP і живі тести провайдерів медіа, а також -обробку облікових даних. +Щоб швидко ознайомитися зі стартом, раннерами QA, наборами unit/integration тестів і Docker-потоками, див. +[Тестування](/uk/help/testing). На цій сторінці описано **живі** (із зверненням до мережі) набори тестів: +матриця моделей, бекенди CLI, ACP і живі тести медіапровайдерів, а також +обробка облікових даних. -## Живе: локальні команди smoke-тестів профілю +## Живе: локальні команди smoke для профілю -Підключіть `~/.profile` перед довільними живими перевірками, щоб ключі провайдерів і локальні шляхи до інструментів -відповідали вашій оболонці: +Виконайте `source ~/.profile` перед довільними живими перевірками, щоб ключі провайдерів і локальні шляхи +до інструментів відповідали вашій оболонці: ```bash source ~/.profile ``` -Безпечний smoke-тест медіа: +Безпечна медіа smoke-перевірка: ```bash pnpm openclaw infer tts convert --local --json \ @@ -37,131 +37,131 @@ pnpm openclaw infer tts convert --local --json \ --output /tmp/openclaw-live-smoke.mp3 ``` -Безпечний smoke-тест готовності голосових викликів: +Безпечна smoke-перевірка готовності голосового дзвінка: ```bash pnpm openclaw voicecall setup --json pnpm openclaw voicecall smoke --to "+15555550123" ``` -`voicecall smoke` — це пробний запуск, якщо також не вказано `--yes`. Використовуйте `--yes` лише -коли ви свідомо хочете здійснити реальний виклик сповіщення. Для Twilio, Telnyx і -Plivo успішна перевірка готовності потребує публічної URL-адреси Webhook; лише локальні -fallback-варіанти loopback/private навмисно відхиляються. +`voicecall smoke` — це сухий запуск, якщо також не вказано `--yes`. Використовуйте `--yes` лише +тоді, коли ви свідомо хочете здійснити реальний сповіщувальний дзвінок. Для Twilio, Telnyx і +Plivo успішна перевірка готовності вимагає публічної URL-адреси Webhook; локальні резервні варіанти +на основі loopback/приватної мережі навмисно відхиляються. ## Живе: повний перегляд можливостей Android Node - Тест: `src/gateway/android-node.capabilities.live.test.ts` - Скрипт: `pnpm android:test:integration` -- Мета: викликати **кожну команду, яку зараз оголошує** підключений Android Node, і перевірити поведінку контракту команди. +- Мета: викликати **кожну команду, яку наразі оголошує** підключений Android Node, і перевірити поведінку контракту команди. - Обсяг: - - Попередньо підготовлене/ручне налаштування (набір не встановлює/не запускає/не спаровує застосунок). - - Перевірка `node.invoke` Gateway для вибраного Android Node команда за командою. -- Необхідне попереднє налаштування: - - Android-застосунок уже підключено й спарено з Gateway. + - Попередньо підготовлене/ручне налаштування (набір тестів не встановлює/не запускає/не спарює застосунок). + - Перевірка `node.invoke` у Gateway для вибраного Android Node, команда за командою. +- Потрібне попереднє налаштування: + - Застосунок Android уже підключено та спарено з Gateway. - Застосунок утримується на передньому плані. - - Для можливостей, які ви очікуєте пройти, надано дозволи/згоду на захоплення. + - Для можливостей, які мають пройти перевірку, надано дозволи/згоду на захоплення. - Необов’язкові перевизначення цілі: - `OPENCLAW_ANDROID_NODE_ID` або `OPENCLAW_ANDROID_NODE_NAME`. - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`. -- Докладні відомості про повне налаштування Android: [Android App](/uk/platforms/android) +- Повні подробиці налаштування Android: [Android App](/uk/platforms/android) -## Живе: smoke-тест моделі (ключі профілю) +## Живе: smoke моделей (ключі профілю) Живі тести поділено на два шари, щоб ми могли ізолювати збої: -- «Пряма модель» показує, чи може провайдер/модель взагалі відповісти з наданим ключем. -- «Smoke-тест Gateway» показує, чи працює для цієї моделі повний конвеєр gateway+agent (сеанси, історія, інструменти, політика sandbox тощо). +- «Пряма модель» показує, чи провайдер/модель взагалі може відповісти з наданим ключем. +- «Smoke Gateway» показує, чи працює для цієї моделі повний конвеєр Gateway+агента (сесії, історія, інструменти, політика sandbox тощо). -### Шар 1: Пряме завершення моделі (без gateway) +### Шар 1: пряме завершення моделі (без Gateway) - Тест: `src/agents/models.profiles.live.test.ts` - Мета: - - Перерахувати виявлені моделі + - Перелічити виявлені моделі - Використати `getApiKeyForModel`, щоб вибрати моделі, для яких у вас є облікові дані - Виконати невелике завершення для кожної моделі (і цільові регресійні перевірки, де потрібно) - Як увімкнути: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо ви викликаєте Vitest напряму) -- Установіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб справді запускати цей набір; інакше його буде пропущено, щоб `pnpm test:live` залишався зосередженим на smoke-тесті gateway -- Як вибрати моделі: - - `OPENCLAW_LIVE_MODELS=modern`, щоб запустити modern allowlist (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4) - - `OPENCLAW_LIVE_MODELS=all` — це псевдонім для modern allowlist - - або `OPENCLAW_LIVE_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,..."` (allowlist через коми) - - Перегляди modern/all за замовчуванням мають підібране обмеження з високим сигналом; установіть `OPENCLAW_LIVE_MAX_MODELS=0` для вичерпного modern-перегляду або додатне число для меншого обмеження. - - Для вичерпних переглядів використовується `OPENCLAW_LIVE_TEST_TIMEOUT_MS` як тайм-аут усього прямого тесту моделі. Типове значення: 60 хвилин. - - Проби прямої моделі за замовчуванням виконуються з паралелізмом у 20 потоків; щоб перевизначити, установіть `OPENCLAW_LIVE_MODEL_CONCURRENCY`. -- Як вибрати провайдерів: - - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist через коми) +- Установіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб дійсно запустити цей набір тестів; інакше його буде пропущено, щоб `pnpm test:live` залишався зосередженим на smoke Gateway +- Як вибирати моделі: + - `OPENCLAW_LIVE_MODELS=modern`, щоб запустити сучасний allowlist (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4) + - `OPENCLAW_LIVE_MODELS=all` — це псевдонім для сучасного allowlist + - або `OPENCLAW_LIVE_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,..."` (allowlist через кому) + - Для переглядів modern/all за замовчуванням використовується підібране обмеження з високою інформативністю; установіть `OPENCLAW_LIVE_MAX_MODELS=0` для вичерпного перегляду modern або додатне число для меншого обмеження. + - Для вичерпних переглядів використовується `OPENCLAW_LIVE_TEST_TIMEOUT_MS` як тайм-аут усього тесту прямої моделі. За замовчуванням: 60 хвилин. + - За замовчуванням перевірки прямої моделі виконуються з паралелізмом 20; щоб перевизначити це, установіть `OPENCLAW_LIVE_MODEL_CONCURRENCY`. +- Як вибирати провайдерів: + - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist через кому) - Звідки беруться ключі: - - За замовчуванням: сховище профілів і fallback через env + - За замовчуванням: сховище профілів і резервні значення env - Установіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати **лише сховище профілів** - Навіщо це існує: - - Відокремлює «API провайдера зламане / ключ недійсний» від «конвеєр gateway agent зламаний» - - Містить малі ізольовані регресії (приклад: потоки повторення міркування OpenAI Responses/Codex Responses + виклик інструментів) + - Відокремлює «API провайдера зламане / ключ недійсний» від «конвеєр агента Gateway зламаний» + - Містить невеликі ізольовані регресії (приклад: повторне відтворення міркувань OpenAI Responses/Codex Responses + потоки виклику інструментів) -### Шар 2: smoke-тест Gateway + dev agent (те, що насправді робить "@openclaw") +### Шар 2: smoke Gateway + dev-агента (що насправді робить "@openclaw") - Тест: `src/gateway/gateway-models.profiles.live.test.ts` - Мета: - - Запустити внутрішньопроцесний Gateway - - Створити/пропатчити сеанс `agent:dev:*` (перевизначення моделі для кожного запуску) - - Ітерувати моделі з ключами та перевіряти: + - Підняти внутрішньопроцесний Gateway + - Створити/змінити сесію `agent:dev:*` (перевизначення моделі для кожного запуску) + - Перебрати моделі з ключами й перевірити: - «змістовну» відповідь (без інструментів) - - роботу реального виклику інструмента (проба читання) - - необов’язкові додаткові проби інструментів (проба exec+read) - - що регресійні шляхи OpenAI (лише tool-call → подальший крок) і далі працюють -- Подробиці проб (щоб ви могли швидко пояснювати збої): - - проба `read`: тест записує файл nonce у робочому просторі й просить agent `read` його та повернути nonce. - - проба `exec+read`: тест просить agent записати nonce у тимчасовий файл через `exec`, а потім прочитати його назад через `read`. - - проба зображення: тест прикріплює згенерований PNG (cat + рандомізований код) і очікує, що модель поверне `cat `. + - що працює реальний виклик інструмента (`read` probe) + - необов’язкові додаткові перевірки інструментів (`exec+read` probe) + - що регресійні шляхи OpenAI (лише виклик інструмента → подальший крок) продовжують працювати +- Подробиці probe (щоб ви могли швидко пояснювати збої): + - `read` probe: тест записує файл із nonce у робочому просторі й просить агента `read` прочитати його та повернути nonce у відповіді. + - `exec+read` probe: тест просить агента `exec` записати nonce у тимчасовий файл, а потім `read` прочитати його назад. + - image probe: тест додає згенерований PNG (cat + випадковий код) й очікує, що модель поверне `cat `. - Посилання на реалізацію: `src/gateway/gateway-models.profiles.live.test.ts` і `src/gateway/live-image-probe.ts`. - Як увімкнути: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо ви викликаєте Vitest напряму) -- Як вибрати моделі: - - За замовчуванням: modern allowlist (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4) - - `OPENCLAW_LIVE_GATEWAY_MODELS=all` — це псевдонім для modern allowlist +- Як вибирати моделі: + - За замовчуванням: сучасний allowlist (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4) + - `OPENCLAW_LIVE_GATEWAY_MODELS=all` — це псевдонім для сучасного allowlist - Або встановіть `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (або список через кому), щоб звузити вибір - - Перегляди modern/all для gateway за замовчуванням мають підібране обмеження з високим сигналом; установіть `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` для вичерпного modern-перегляду або додатне число для меншого обмеження. -- Як вибрати провайдерів (уникнути «OpenRouter everything»): - - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist через коми) -- Проби інструментів і зображень у цьому живому тесті завжди ввімкнені: - - проба `read` + проба `exec+read` (навантаження на інструменти) - - проба зображення запускається, коли модель заявляє підтримку введення зображень + - Для переглядів modern/all у Gateway за замовчуванням використовується підібране обмеження з високою інформативністю; установіть `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` для вичерпного перегляду modern або додатне число для меншого обмеження. +- Як вибирати провайдерів (уникнути сценарію «усе OpenRouter»): + - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist через кому) +- Перевірки інструментів і зображень у цьому живому тесті завжди ввімкнені: + - `read` probe + `exec+read` probe (навантажувальна перевірка інструментів) + - image probe виконується, коли модель оголошує підтримку вхідних зображень - Потік (на високому рівні): - - Тест генерує крихітний PNG з «CAT» + випадковим кодом (`src/gateway/live-image-probe.ts`) + - Тест генерує крихітний PNG із “CAT” + випадковим кодом (`src/gateway/live-image-probe.ts`) - Надсилає його через `agent` `attachments: [{ mimeType: "image/png", content: "" }]` - Gateway розбирає вкладення в `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - - Вбудований agent передає моделі мультимодальне повідомлення користувача - - Перевірка: відповідь містить `cat` + код (допуск OCR: незначні помилки дозволені) + - Вбудований агент передає мультимодальне повідомлення користувача моделі + - Перевірка: відповідь містить `cat` + код (стійкість до OCR: незначні помилки допускаються) -Порада: щоб побачити, що саме можна тестувати на вашій машині (і точні ідентифікатори `provider/model`), виконайте: +Порада: щоб побачити, що ви можете тестувати на своїй машині (і точні ідентифікатори `provider/model`), виконайте: ```bash openclaw models list openclaw models list --json ``` -## Живе: smoke-тест бекенду CLI (Claude, Codex, Gemini або інші локальні CLI) +## Живе: smoke бекенду CLI (Claude, Codex, Gemini або інші локальні CLI) - Тест: `src/gateway/gateway-cli-backend.live.test.ts` -- Мета: перевірити конвеєр Gateway + agent з використанням локального бекенду CLI, не торкаючись вашої типової конфігурації. -- Типові значення smoke-тестів, специфічні для бекенду, знаходяться у визначенні `cli-backend.ts` відповідного розширення-власника. +- Мета: перевірити конвеєр Gateway + агента з використанням локального бекенду CLI, не торкаючись вашої типової конфігурації. +- Типові параметри smoke для конкретного бекенду містяться у визначенні `cli-backend.ts` розширення-власника. - Увімкнення: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо ви викликаєте Vitest напряму) - `OPENCLAW_LIVE_CLI_BACKEND=1` - Типові значення: - Типовий провайдер/модель: `claude-cli/claude-sonnet-4-6` - - Поведінка command/args/image береться з метаданих Plugin CLI-бекенду-власника. + - Поведінка command/args/image походить із метаданих plugin бекенду CLI-власника. - Перевизначення (необов’язково): - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.2"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'` - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, щоб надіслати реальне вкладення-зображення (шляхи впроваджуються у prompt). У рецептах Docker це за замовчуванням вимкнено, якщо явно не запитано. - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, щоб передавати шляхи до файлів зображень як аргументи CLI замість впровадження в prompt. - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`), щоб керувати передаванням аргументів зображень, коли встановлено `IMAGE_ARG`. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, щоб надіслати реальне вкладення зображення (шляхи інжектуються в prompt). У рецептах Docker це типово вимкнено, якщо явно не запитано. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, щоб передавати шляхи до файлів зображень як аргументи CLI замість інжекції в prompt. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`), щоб керувати тим, як передаються аргументи зображень, коли встановлено `IMAGE_ARG`. - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, щоб надіслати другий хід і перевірити потік відновлення. - - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1`, щоб увімкнути пробу безперервності того самого сеансу Claude Sonnet -> Opus, коли вибрана модель підтримує ціль перемикання. У рецептах Docker це за замовчуванням вимкнено для загальної надійності. - - `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1`, щоб увімкнути loopback-пробу MCP/інструмента. У рецептах Docker це за замовчуванням вимкнено, якщо явно не запитано. + - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1`, щоб увімкнути перевірку безперервності тієї самої сесії Claude Sonnet -> Opus, коли вибрана модель підтримує ціль перемикання. У рецептах Docker це типово вимкнено для загальної надійності. + - `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1`, щоб увімкнути loopback-перевірку MCP/інструментів. У рецептах Docker це типово вимкнено, якщо явно не запитано. Приклад: @@ -177,7 +177,7 @@ OPENCLAW_LIVE_CLI_BACKEND=1 \ pnpm test:docker:live-cli-backend ``` -Рецепти Docker для одного провайдера: +Docker-рецепти для одного провайдера: ```bash pnpm test:docker:live-cli-backend:claude @@ -188,40 +188,43 @@ pnpm test:docker:live-cli-backend:gemini Примітки: -- Раннер Docker знаходиться тут: `scripts/test-live-cli-backend-docker.sh`. -- Він запускає живий smoke-тест CLI-бекенду всередині Docker-образу репозиторію від імені непривілейованого користувача `node`. -- Він визначає метадані smoke-тесту CLI з розширення-власника, а потім встановлює відповідний Linux-пакет CLI (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`) у кешований каталог із правом запису за префіксом `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (типово: `~/.cache/openclaw/docker-cli-tools`). -- `pnpm test:docker:live-cli-backend:claude-subscription` потребує portable Claude Code subscription OAuth через `~/.claude/.credentials.json` з `claudeAiOauth.subscriptionType` або `CLAUDE_CODE_OAUTH_TOKEN` із `claude setup-token`. Спочатку він підтверджує прямий `claude -p` у Docker, а потім виконує два ходи Gateway CLI-бекенду без збереження змінних середовища ключа Anthropic API. Для цього шляху підписки за замовчуванням вимкнено проби Claude MCP/інструмента та зображень, оскільки Claude наразі маршрутизує використання сторонніх застосунків через оплату за додаткове використання, а не через звичайні ліміти плану підписки. -- Живий smoke-тест CLI-бекенду тепер виконує той самий наскрізний потік для Claude, Codex і Gemini: текстовий хід, хід класифікації зображення, а потім виклик інструмента MCP `cron`, перевірений через gateway CLI. -- Типовий smoke-тест Claude також патчить сеанс із Sonnet на Opus і перевіряє, що відновлений сеанс усе ще пам’ятає попередню нотатку. +- Docker runner розташовано в `scripts/test-live-cli-backend-docker.sh`. +- Він запускає живу smoke-перевірку CLI-бекенду всередині Docker-образу репозиторію від імені непривілейованого користувача `node`. +- Він визначає метадані CLI smoke з розширення-власника, а потім встановлює відповідний Linux-пакет CLI (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`) у кешований доступний для запису префікс за адресою `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (типово: `~/.cache/openclaw/docker-cli-tools`). +- `pnpm test:docker:live-cli-backend:claude-subscription` вимагає переносиму OAuth-підписку Claude Code через `~/.claude/.credentials.json` із `claudeAiOauth.subscriptionType` або `CLAUDE_CODE_OAUTH_TOKEN` із `claude setup-token`. Спочатку він доводить прямий `claude -p` у Docker, а потім виконує два ходи Gateway CLI-backend без збереження env-змінних ключів Anthropic API. Ця гілка підписки типово вимикає перевірки Claude MCP/інструментів і зображень, тому що Claude наразі маршрутизує використання сторонніх застосунків через тарифікацію за додаткове використання замість звичайних лімітів плану підписки. +- Жива smoke-перевірка CLI-бекенду тепер виконує однаковий наскрізний потік для Claude, Codex і Gemini: текстовий хід, хід класифікації зображення, потім виклик інструмента MCP `cron`, перевірений через Gateway CLI. +- Типова smoke-перевірка Claude також змінює сесію із Sonnet на Opus і перевіряє, що відновлена сесія все ще пам’ятає раніше зроблену нотатку. -## Живе: smoke-тест прив’язки ACP (`/acp spawn ... --bind here`) +## Живе: smoke прив’язки ACP (`/acp spawn ... --bind here`) - Тест: `src/gateway/gateway-acp-bind.live.test.ts` -- Мета: перевірити реальний потік conversation-bind ACP із живим ACP agent: +- Мета: перевірити реальний потік прив’язки розмови ACP з живим ACP-агентом: - надіслати `/acp spawn --bind here` - прив’язати синтетичну розмову каналу повідомлень на місці - - надіслати звичайний подальший запит у тій самій розмові - - перевірити, що подальший запит потрапляє до стенограми прив’язаного сеансу ACP + - надіслати звичайний подальший крок у цій самій розмові + - перевірити, що подальший крок потрапив у транскрипт прив’язаної сесії ACP - Увімкнення: - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` - Типові значення: - - ACP agents у Docker: `claude,codex,gemini` - - ACP agent для прямого `pnpm test:live ...`: `claude` - - Синтетичний канал: контекст розмови у стилі Slack DM + - ACP-агенти в Docker: `claude,codex,gemini` + - ACP-агент для прямого `pnpm test:live ...`: `claude` + - Синтетичний канал: контекст розмови в стилі Slack DM - Бекенд ACP: `acpx` - Перевизначення: - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude` - `OPENCLAW_LIVE_ACP_BIND_AGENT=codex` - `OPENCLAW_LIVE_ACP_BIND_AGENT=gemini` + - `OPENCLAW_LIVE_ACP_BIND_AGENT=opencode` - `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` - `OPENCLAW_LIVE_ACP_BIND_CODEX_MODEL=gpt-5.2` + - `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL=opencode/kimi-k2.6` + - `OPENCLAW_LIVE_ACP_BIND_REQUIRE_TRANSCRIPT=1` - `OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.2` - Примітки: - - Цей шлях використовує поверхню gateway `chat.send` з адміністративними синтетичними полями originating-route, щоб тести могли приєднати контекст каналу повідомлень без удавання зовнішньої доставки. - - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не встановлено, тест використовує вбудований реєстр agent вбудованого Plugin `acpx` для вибраного ACP harness agent. + - Ця гілка використовує поверхню gateway `chat.send` з адміністративними полями synthetic originating-route, щоб тести могли додавати контекст каналу повідомлень без імітації зовнішньої доставки. + - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не задано, тест використовує вбудований реєстр агентів plugin `acpx` для вибраного ACP harness-агента. Приклад: @@ -231,53 +234,55 @@ OPENCLAW_LIVE_ACP_BIND=1 \ pnpm test:live src/gateway/gateway-acp-bind.live.test.ts ``` -Рецепт Docker: +Docker-рецепт: ```bash pnpm test:docker:live-acp-bind ``` -Рецепти Docker для одного agent: +Docker-рецепти для одного агента: ```bash pnpm test:docker:live-acp-bind:claude pnpm test:docker:live-acp-bind:codex pnpm test:docker:live-acp-bind:gemini +pnpm test:docker:live-acp-bind:opencode ``` Примітки щодо Docker: -- Раннер Docker знаходиться тут: `scripts/test-live-acp-bind-docker.sh`. -- За замовчуванням він запускає smoke-тест прив’язки ACP послідовно для всіх підтримуваних живих агентів CLI: `claude`, `codex`, потім `gemini`. -- Використовуйте `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` або `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini`, щоб звузити матрицю. -- Він підключає `~/.profile`, готує відповідні матеріали автентифікації CLI в контейнері, установлює `acpx` у npm-префікс із правом запису, а потім установлює запитаний живий CLI (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`), якщо його немає. -- Усередині Docker раннер встановлює `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, щоб `acpx` зберігав змінні середовища провайдера з підключеного профілю доступними для дочірнього CLI harness. +- Docker runner розташовано в `scripts/test-live-acp-bind-docker.sh`. +- За замовчуванням він запускає smoke-перевірку ACP bind для сукупних живих CLI-агентів послідовно: `claude`, `codex`, потім `gemini`. +- Використовуйте `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` або `OPENCLAW_LIVE_ACP_BIND_AGENTS=opencode`, щоб звузити матрицю. +- Він виконує `source ~/.profile`, готує відповідні матеріали автентифікації CLI в контейнері, а потім встановлює запитаний живий CLI (`@anthropic-ai/claude-code`, `@openai/codex`, `@google/gemini-cli` або `opencode-ai`), якщо його немає. Сам бекенд ACP — це вбудований пакет `acpx/runtime` з plugin `acpx`. +- Варіант Docker для OpenCode — це сувора регресійна гілка для одного агента. Після виконання `source ~/.profile` він записує тимчасову типову модель `OPENCODE_CONFIG_CONTENT` з `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (типово `opencode/kimi-k2.6`), а `pnpm test:docker:live-acp-bind:opencode` вимагає прив’язаного транскрипту асистента замість прийняття загального пропуску після bind. +- Прямі виклики CLI `acpx` — це лише ручний/обхідний шлях для порівняння поведінки поза Gateway. Docker smoke-перевірка ACP bind перевіряє вбудований бекенд runtime `acpx` в OpenClaw. -## Живе: smoke-тест harness app-server Codex +## Живе: smoke Codex app-server harness -- Мета: перевірити harness Codex, яким володіє Plugin, через звичайний метод gateway - `agent`: - - завантажити вбудований Plugin `codex` +- Мета: перевірити harness Codex, що належить plugin, через звичайний + метод gateway `agent`: + - завантажити вбудований plugin `codex` - вибрати `OPENCLAW_AGENT_RUNTIME=codex` - - надіслати перший хід gateway agent до `openai/gpt-5.2` із примусовим використанням harness Codex - - надіслати другий хід у той самий сеанс OpenClaw і перевірити, що потік + - надіслати перший хід gateway agent до `openai/gpt-5.2` із примусово вибраним harness Codex + - надіслати другий хід до тієї самої сесії OpenClaw і перевірити, що потік app-server може відновитися - - запустити `/codex status` і `/codex models` через той самий шлях команди - gateway - - необов’язково запустити дві ескальовані shell-проби, перевірені Guardian: одну безпечну - команду, яку слід схвалити, і одне фальшиве вивантаження секрету, яке слід - відхилити, щоб agent перепитав + - виконати `/codex status` і `/codex models` через той самий командний + шлях gateway + - за потреби виконати дві перевірки оболонки з підвищеними правами, схвалені Guardian: одну безпечну + команду, яку слід дозволити, і одне фіктивне вивантаження секрету, яке має бути + відхилене, щоб агент перепитав - Тест: `src/gateway/gateway-codex-harness.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_CODEX_HARNESS=1` - Типова модель: `openai/gpt-5.2` -- Необов’язкова проба зображення: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` -- Необов’язкова проба MCP/інструмента: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` -- Необов’язкова проба Guardian: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1` -- Smoke-тест установлює `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, щоб зламаний harness Codex - не міг пройти, непомітно переключившись на fallback до Pi. -- Автентифікація: автентифікація app-server Codex із локального входу до підписки Codex. Docker - smoke-тести також можуть надавати `OPENAI_API_KEY` для не-Codex проб, де це застосовно, - а також необов’язково скопійовані `~/.codex/auth.json` і `~/.codex/config.toml`. +- Необов’язкова image probe: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` +- Необов’язкова MCP/tool probe: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` +- Необов’язкова Guardian probe: `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1` +- Для smoke встановлюється `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, щоб зламаний Codex + harness не міг пройти, непомітно переключившись на резервний PI. +- Автентифікація: автентифікація Codex app-server із локального входу до підписки Codex. Docker + smoke-перевірки також можуть надавати `OPENAI_API_KEY` для не-Codex перевірок, де це застосовно, + а також за потреби скопійовані `~/.codex/auth.json` і `~/.codex/config.toml`. Локальний рецепт: @@ -291,7 +296,7 @@ OPENCLAW_LIVE_CODEX_HARNESS=1 \ pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts ``` -Рецепт Docker: +Docker-рецепт: ```bash source ~/.profile @@ -300,59 +305,59 @@ pnpm test:docker:live-codex-harness Примітки щодо Docker: -- Раннер Docker знаходиться тут: `scripts/test-live-codex-harness-docker.sh`. -- Він підключає змонтований `~/.profile`, передає `OPENAI_API_KEY`, копіює файли - автентифікації CLI Codex, якщо вони є, установлює `@openai/codex` у змонтований npm-префікс - із правом запису, готує дерево джерел, а потім запускає лише живий тест Codex-harness. -- У Docker проби зображення, MCP/інструмента та Guardian увімкнені за замовчуванням. Установіть +- Docker runner розташовано в `scripts/test-live-codex-harness-docker.sh`. +- Він виконує `source` для змонтованого `~/.profile`, передає `OPENAI_API_KEY`, копіює файли + автентифікації CLI Codex за наявності, встановлює `@openai/codex` у доступний для запису змонтований npm + префікс, готує дерево вихідного коду, а потім запускає лише живий тест Codex-harness. +- Docker типово вмикає image, MCP/tool і Guardian probe. Установіть `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` або `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0` або `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0`, коли потрібен вужчий налагоджувальний запуск. - Docker також експортує `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, що відповідає конфігурації живого - тесту, щоб застарілі псевдоніми або fallback до Pi не могли приховати регресію - harness Codex. + тесту, тож застарілі псевдоніми або резервний PI не можуть приховати регресію + Codex harness. ### Рекомендовані живі рецепти -Вузькі, явні allowlist працюють найшвидше й найменше схильні до збоїв: +Вузькі, явні allowlist — найшвидші й найменш схильні до збоїв: -- Одна модель, напряму (без gateway): +- Одна модель, напряму (без Gateway): - `OPENCLAW_LIVE_MODELS="openai/gpt-5.2" pnpm test:live src/agents/models.profiles.live.test.ts` -- Одна модель, smoke-тест gateway: +- Одна модель, smoke Gateway: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.2" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Виклик інструментів для кількох провайдерів: +- Виклик інструментів через кількох провайдерів: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,deepseek/deepseek-v4-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Фокус на Google (ключ API Gemini + Antigravity): - Gemini (ключ API): `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Antigravity (OAuth): `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Smoke-тест адаптивного мислення Google: - - Якщо локальні ключі знаходяться в профілі shell: `source ~/.profile` - - Gemini 3 dynamic default: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000` - - Gemini 2.5 dynamic budget: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-2.5-flash --alt-model google/gemini-2.5-flash --message '/think adaptive Reply exactly: GEMINI25_ADAPTIVE_OK' --timeout-ms 180000` +- Жива smoke-перевірка адаптивного мислення Google: + - Якщо локальні ключі містяться в профілі оболонки: `source ~/.profile` + - Динамічний типовий Gemini 3: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000` + - Динамічний бюджет Gemini 2.5: `pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-2.5-flash --alt-model google/gemini-2.5-flash --message '/think adaptive Reply exactly: GEMINI25_ADAPTIVE_OK' --timeout-ms 180000` Примітки: - `google/...` використовує API Gemini (ключ API). -- `google-antigravity/...` використовує міст OAuth Antigravity (кінцева точка agent у стилі Cloud Code Assist). +- `google-antigravity/...` використовує OAuth-міст Antigravity (кінцева точка агента в стилі Cloud Code Assist). - `google-gemini-cli/...` використовує локальний Gemini CLI на вашій машині (окрема автентифікація + особливості інструментів). - API Gemini проти Gemini CLI: - - API: OpenClaw викликає розміщений Google API Gemini через HTTP (автентифікація через ключ API / профіль); саме це більшість користувачів мають на увазі під «Gemini». - - CLI: OpenClaw викликає локальний бінарник `gemini`; він має власну автентифікацію й може поводитися інакше (streaming/підтримка інструментів/розбіжність версій). + - API: OpenClaw викликає розміщений Google API Gemini через HTTP (автентифікація ключем API / профілем); саме це більшість користувачів мають на увазі під «Gemini». + - CLI: OpenClaw викликає локальний двійковий файл `gemini`; він має власну автентифікацію і може поводитися інакше (streaming/підтримка інструментів/розходження версій). ## Живе: матриця моделей (що ми покриваємо) -Фіксованого «списку моделей CI» немає (живі тести вмикаються за бажанням), але ось **рекомендовані** моделі для регулярного покриття на машині розробника з ключами. +Фіксованого «списку моделей CI» немає (живі тести — opt-in), але це **рекомендовані** моделі, які слід регулярно покривати на машині розробника з ключами. -### Сучасний набір smoke-тестів (виклик інструментів + зображення) +### Сучасний набір smoke (виклик інструментів + зображення) -Це запуск «поширених моделей», який, як ми очікуємо, має залишатися працездатним: +Це запуск «поширених моделей», який ми очікуємо зберігати працездатним: -- OpenAI (не-Codex): `openai/gpt-5.2` +- OpenAI (не Codex): `openai/gpt-5.2` - OpenAI Codex OAuth: `openai-codex/gpt-5.2` - Anthropic: `anthropic/claude-opus-4-6` (або `anthropic/claude-sonnet-4-6`) - Google (API Gemini): `google/gemini-3.1-pro-preview` і `google/gemini-3-flash-preview` (уникайте старіших моделей Gemini 2.x) @@ -361,12 +366,12 @@ pnpm test:docker:live-codex-harness - Z.AI (GLM): `zai/glm-4.7` - MiniMax: `minimax/MiniMax-M2.7` -Запуск smoke-тесту gateway з інструментами + зображенням: +Запустіть smoke Gateway з інструментами + зображенням: `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,deepseek/deepseek-v4-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` ### Базовий рівень: виклик інструментів (Read + необов’язковий Exec) -Виберіть принаймні одну модель для кожної сім’ї провайдерів: +Виберіть щонайменше одну модель для кожного сімейства провайдерів: - OpenAI: `openai/gpt-5.2` - Anthropic: `anthropic/claude-opus-4-6` (або `anthropic/claude-sonnet-4-6`) @@ -375,51 +380,51 @@ pnpm test:docker:live-codex-harness - Z.AI (GLM): `zai/glm-4.7` - MiniMax: `minimax/MiniMax-M2.7` -Необов’язкове додаткове покриття (бажано мати): +Необов’язкове додаткове покриття (було б добре мати): - xAI: `xai/grok-4` (або найновіша доступна) -- Mistral: `mistral/`… (виберіть одну модель із підтримкою `tools`, яку у вас ввімкнено) -- Cerebras: `cerebras/`… (якщо у вас є доступ) +- Mistral: `mistral/`… (виберіть одну модель із підтримкою “tools”, яку у вас ввімкнено) +- Cerebras: `cerebras/`… (якщо маєте доступ) - LM Studio: `lmstudio/`… (локально; виклик інструментів залежить від режиму API) ### Vision: надсилання зображення (вкладення → мультимодальне повідомлення) -Додайте принаймні одну модель із підтримкою зображень у `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/варіанти OpenAI із підтримкою vision тощо), щоб перевірити пробу зображення. +Додайте щонайменше одну модель із підтримкою зображень у `OPENCLAW_LIVE_GATEWAY_MODELS` (варіанти Claude/Gemini/OpenAI із підтримкою vision тощо), щоб перевірити image probe. -### Агрегатори / альтернативні gateway +### Агрегатори / альтернативні Gateway Якщо у вас увімкнено ключі, ми також підтримуємо тестування через: -- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти кандидатів із підтримкою `tool`+`image`) +- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти кандидатів із підтримкою tools+image) - OpenCode: `opencode/...` для Zen і `opencode-go/...` для Go (автентифікація через `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) -Інші провайдери, яких можна включити до живої матриці (якщо у вас є облікові дані/конфігурація): +Більше провайдерів, які можна включити до живої матриці (якщо у вас є облікові дані/конфігурація): - Вбудовані: `openai`, `openai-codex`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot` -- Через `models.providers` (власні кінцеві точки): `minimax` (хмара/API), а також будь-який сумісний із OpenAI/Anthropic проксі (LM Studio, vLLM, LiteLLM тощо) +- Через `models.providers` (власні кінцеві точки): `minimax` (хмара/API), а також будь-який OpenAI/Anthropic-сумісний проксі (LM Studio, vLLM, LiteLLM тощо) -Порада: не намагайтеся жорстко прописати в документації «всі моделі». Авторитетний список — це те, що `discoverModels(...)` повертає на вашій машині + які ключі доступні. +Порада: не намагайтеся жорстко фіксувати в документації «усі моделі». Авторитетний список — це все, що повертає `discoverModels(...)` на вашій машині, плюс усі доступні ключі. ## Облікові дані (ніколи не комітьте) -Живі тести виявляють облікові дані так само, як це робить CLI. Практичні наслідки: +Живі тести виявляють облікові дані так само, як і CLI. Практичні наслідки: -- Якщо CLI працює, живі тести мають знаходити ті самі ключі. -- Якщо живий тест повідомляє «немає облікових даних», налагоджуйте це так само, як ви налагоджували б `openclaw models list` / вибір моделі. +- Якщо CLI працює, живі тести повинні знаходити ті самі ключі. +- Якщо живий тест каже «немає облікових даних», налагоджуйте це так само, як ви налагоджували б `openclaw models list` / вибір моделі. -- Профілі автентифікації для кожного agent: `~/.openclaw/agents//agent/auth-profiles.json` (саме це в живих тестах означає «ключі профілю») +- Профілі автентифікації для кожного агента: `~/.openclaw/agents//agent/auth-profiles.json` (саме це у живих тестах означає «ключі профілю») - Конфігурація: `~/.openclaw/openclaw.json` (або `OPENCLAW_CONFIG_PATH`) -- Застарілий каталог стану: `~/.openclaw/credentials/` (копіюється в підготовлений живий home, якщо присутній, але це не основне сховище ключів профілю) -- Локальні живі запуски за замовчуванням копіюють активну конфігурацію, файли `auth-profiles.json` для кожного agent, застарілий `credentials/` і підтримувані зовнішні каталоги автентифікації CLI до тимчасового тестового home; у підготовлених живих home пропускаються `workspace/` і `sandboxes/`, а перевизначення шляхів `agents.*.workspace` / `agentDir` видаляються, щоб проби не торкалися вашого реального робочого простору хоста. +- Застарілий каталог стану: `~/.openclaw/credentials/` (копіюється до staged live home за наявності, але це не основне сховище ключів профілю) +- Локальні живі запуски типово копіюють активну конфігурацію, файли `auth-profiles.json` для кожного агента, застарілий `credentials/` і підтримувані зовнішні каталоги автентифікації CLI до тимчасового test home; staged live home пропускають `workspace/` і `sandboxes/`, а перевизначення шляхів `agents.*.workspace` / `agentDir` прибираються, щоб перевірки не торкалися вашого реального робочого простору хоста. -Якщо ви хочете покладатися на ключі env (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile` або використовуйте наведені нижче раннери Docker (вони можуть монтувати `~/.profile` у контейнер). +Якщо ви хочете покладатися на env-ключі (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile`, або використовуйте наведені нижче Docker runner-и (вони можуть монтувати `~/.profile` у контейнер). ## Живе: Deepgram (транскрибування аудіо) - Тест: `extensions/deepgram/audio.live.test.ts` - Увімкнення: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live extensions/deepgram/audio.live.test.ts` -## Живе: coding plan BytePlus +## Живе: план кодування BytePlus - Тест: `extensions/byteplus/live.test.ts` - Увімкнення: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts` @@ -430,9 +435,9 @@ pnpm test:docker:live-codex-harness - Тест: `extensions/comfy/comfy.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` - Обсяг: - - Перевіряє вбудовані шляхи comfy для зображень, відео та `music_generate` + - Перевіряє вбудовані шляхи comfy для зображень, відео і `music_generate` - Пропускає кожну можливість, якщо не налаштовано `plugins.entries.comfy.config.` - - Корисно після змін у надсиланні workflow comfy, опитуванні, завантаженнях або реєстрації Plugin + - Корисно після змін у надсиланні workflow comfy, опитуванні, завантаженнях або реєстрації plugin ## Живе: генерація зображень @@ -440,13 +445,13 @@ pnpm test:docker:live-codex-harness - Команда: `pnpm test:live test/image-generation.runtime.live.test.ts` - Harness: `pnpm test:live:media image` - Обсяг: - - Перераховує кожен зареєстрований Plugin провайдера генерації зображень - - Завантажує відсутні env-змінні провайдера з вашої оболонки входу (`~/.profile`) перед пробами + - Перелічує кожен зареєстрований plugin провайдера генерації зображень + - Завантажує відсутні env-змінні провайдерів із вашої login shell (`~/.profile`) перед перевіркою - За замовчуванням використовує живі/env API-ключі раніше за збережені профілі автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки - Пропускає провайдерів без придатної автентифікації/профілю/моделі - - Проганяє кожного налаштованого провайдера через спільний runtime генерації зображень: + - Запускає кожного налаштованого провайдера через спільний runtime генерації зображень: - `:generate` - - `:edit`, коли провайдер заявляє підтримку редагування + - `:edit`, коли провайдер оголошує підтримку редагування - Поточні вбудовані провайдери, які покриваються: - `fal` - `google` @@ -460,10 +465,10 @@ pnpm test:docker:live-codex-harness - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-2,google/gemini-3.1-flash-image-preview,openrouter/google/gemini-3.1-flash-image-preview,xai/grok-imagine-image"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit,openrouter:generate,xai:default-generate,xai:default-edit"` - Необов’язкова поведінка автентифікації: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію через сховище профілів і ігнорувати перевизначення лише через env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію зі сховища профілів і ігнорувати перевизначення лише через env -Для шляху CLI, що постачається, додайте smoke-тест `infer` після того, як живий -тест провайдера/runtime пройде успішно: +Для шляху shipped CLI додайте smoke-перевірку `infer` після того, як живий тест +провайдера/runtime пройде: ```bash OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_INFER_CLI_TEST=1 pnpm test:live -- test/image-generation.infer-cli.live.test.ts @@ -476,7 +481,7 @@ openclaw infer image generate \ ``` Це покриває розбір аргументів CLI, визначення config/default-agent, активацію вбудованого -Plugin, ремонт залежностей runtime на вимогу, спільний +plugin, відновлення залежностей bundled runtime на вимогу, спільний runtime генерації зображень і живий запит до провайдера. ## Живе: генерація музики @@ -485,15 +490,15 @@ runtime генерації зображень і живий запит до пр - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Harness: `pnpm test:live:media music` - Обсяг: - - Перевіряє спільний шлях вбудованого провайдера генерації музики + - Перевіряє спільний шлях bundled-провайдера генерації музики - Наразі покриває Google і MiniMax - - Завантажує env-змінні провайдера з вашої оболонки входу (`~/.profile`) перед пробами + - Завантажує env-змінні провайдерів із вашої login shell (`~/.profile`) перед перевіркою - За замовчуванням використовує живі/env API-ключі раніше за збережені профілі автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки - Пропускає провайдерів без придатної автентифікації/профілю/моделі - - Запускає обидва заявлені режими runtime, коли вони доступні: - - `generate` з введенням лише prompt - - `edit`, коли провайдер заявляє `capabilities.edit.enabled` - - Поточне покриття спільного шляху: + - Запускає обидва оголошені режими runtime, коли вони доступні: + - `generate` з вхідними даними лише у вигляді prompt + - `edit`, коли провайдер оголошує `capabilities.edit.enabled` + - Поточне покриття у спільній гілці: - `google`: `generate`, `edit` - `minimax`: `generate` - `comfy`: окремий живий файл Comfy, не цей спільний перегляд @@ -501,7 +506,7 @@ runtime генерації зображень і живий запит до пр - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.6"` - Необов’язкова поведінка автентифікації: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію через сховище профілів і ігнорувати перевизначення лише через env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію зі сховища профілів і ігнорувати перевизначення лише через env ## Живе: генерація відео @@ -509,43 +514,43 @@ runtime генерації зображень і живий запит до пр - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harness: `pnpm test:live:media video` - Обсяг: - - Перевіряє спільний шлях вбудованого провайдера генерації відео - - За замовчуванням використовує безпечний для релізу шлях smoke-тесту: провайдери не-FAL, один запит text-to-video на провайдера, односекундний lobster-prompt і обмеження операції на провайдера з `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` за замовчуванням) + - Перевіряє спільний шлях bundled-провайдера генерації відео + - За замовчуванням використовує безпечний для релізу шлях smoke: провайдери не-FAL, один запит text-to-video на провайдера, односекундний prompt із лобстером і обмеження операції для кожного провайдера з `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` за замовчуванням) - За замовчуванням пропускає FAL, оскільки затримка черги на боці провайдера може домінувати в часі релізу; передайте `--video-providers fal` або `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"`, щоб запустити його явно - - Завантажує env-змінні провайдера з вашої оболонки входу (`~/.profile`) перед пробами + - Завантажує env-змінні провайдерів із вашої login shell (`~/.profile`) перед перевіркою - За замовчуванням використовує живі/env API-ключі раніше за збережені профілі автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки - Пропускає провайдерів без придатної автентифікації/профілю/моделі - За замовчуванням запускає лише `generate` - - Установіть `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, щоб також запускати заявлені режими трансформації, коли вони доступні: - - `imageToVideo`, коли провайдер заявляє `capabilities.imageToVideo.enabled` і вибраний провайдер/модель приймає локальне введення зображення на основі buffer у спільному перегляді - - `videoToVideo`, коли провайдер заявляє `capabilities.videoToVideo.enabled` і вибраний провайдер/модель приймає локальне введення відео на основі buffer у спільному перегляді - - Поточні заявлені, але пропущені провайдери `imageToVideo` у спільному перегляді: - - `vydra`, оскільки вбудований `veo3` є лише text-only, а вбудований `kling` потребує віддаленої URL-адреси зображення - - Покриття Vydra, специфічне для провайдера: + - Установіть `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, щоб також запускати оголошені режими transform, коли вони доступні: + - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled` і вибраний провайдер/модель приймає локальний вхід зображення на основі buffer у спільному перегляді + - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled` і вибраний провайдер/модель приймає локальний вхід відео на основі buffer у спільному перегляді + - Поточні провайдери `imageToVideo`, оголошені, але пропущені у спільному перегляді: + - `vydra`, тому що вбудований `veo3` підтримує лише text-to-video, а вбудований `kling` вимагає віддалену URL-адресу зображення + - Специфічне для провайдера покриття Vydra: - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - - цей файл запускає `veo3` text-to-video плюс шлях `kling`, який за замовчуванням використовує віддалений fixture URL-адреси зображення + - цей файл запускає `veo3` text-to-video плюс гілку `kling`, яка за замовчуванням використовує fixture віддаленої URL-адреси зображення - Поточне живе покриття `videoToVideo`: - лише `runway`, коли вибрана модель — `runway/gen4_aleph` - - Поточні заявлені, але пропущені провайдери `videoToVideo` у спільному перегляді: - - `alibaba`, `qwen`, `xai`, оскільки ці шляхи зараз потребують віддалених опорних URL-адрес `http(s)` / MP4 - - `google`, оскільки поточний спільний шлях Gemini/Veo використовує локальне введення на основі buffer, і цей шлях не приймається в спільному перегляді - - `openai`, оскільки поточний спільний шлях не гарантує доступу до відео inpaint/remix, специфічного для організації + - Поточні провайдери `videoToVideo`, оголошені, але пропущені у спільному перегляді: + - `alibaba`, `qwen`, `xai`, тому що ці шляхи наразі вимагають віддалені URL-адреси посилань `http(s)` / MP4 + - `google`, тому що поточна спільна гілка Gemini/Veo використовує локальний вхід на основі buffer, і цей шлях не приймається у спільному перегляді + - `openai`, тому що поточна спільна гілка не має гарантій доступу до video inpaint/remix, специфічних для org - Необов’язкове звуження: - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="google,openai,runway"` - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"` - - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""`, щоб включити кожного провайдера в типовий перегляд, зокрема FAL - - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, щоб зменшити обмеження операції кожного провайдера для агресивного smoke-запуску + - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""`, щоб включити кожного провайдера до типового перегляду, зокрема FAL + - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, щоб зменшити обмеження операції для кожного провайдера в агресивному smoke-запуску - Необов’язкова поведінка автентифікації: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію через сховище профілів і ігнорувати перевизначення лише через env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію зі сховища профілів і ігнорувати перевизначення лише через env -## Media live harness +## Harness для живих медіатестів - Команда: `pnpm test:live:media` - Призначення: - - Запускає спільні живі набори для зображень, музики й відео через одну нативну точку входу репозиторію - - Автоматично завантажує відсутні env-змінні провайдера з `~/.profile` - - За замовчуванням автоматично звужує кожен набір до провайдерів, які наразі мають придатну автентифікацію - - Повторно використовує `scripts/test-live.mjs`, тому поведінка Heartbeat і quiet-mode залишається узгодженою + - Запускає спільні живі набори тестів для зображень, музики й відео через одну вбудовану точку входу репозиторію + - Автоматично завантажує відсутні env-змінні провайдерів із `~/.profile` + - За замовчуванням автоматично звужує кожен набір тестів до провайдерів, для яких наразі є придатна автентифікація + - Повторно використовує `scripts/test-live.mjs`, тож поведінка Heartbeat і тихого режиму залишається узгодженою - Приклади: - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` @@ -554,4 +559,4 @@ runtime генерації зображень і живий запит до пр ## Пов’язане -- [Тестування](/uk/help/testing) — модульні, інтеграційні, QA та Docker-набори +- [Тестування](/uk/help/testing) — набори unit, integration, QA і Docker тестів diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index 6c2e3477d..cac72e67b 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -1,15 +1,15 @@ --- read_when: - Запуск тестів локально або в CI - - Додавання регресійних тестів для багів моделі/провайдера - - Налагодження поведінки Gateway + агента -summary: 'Набір для тестування: модульні/e2e/live набори, Docker-ранери та що охоплює кожен тест' + - Додавання регресійних тестів для багів моделей/провайдерів + - Налагодження поведінки Gateway + агентів +summary: 'Набір для тестування: набори unit/e2e/live, Docker-ранери та що охоплює кожен тест' title: Тестування x-i18n: - generated_at: "2026-04-25T12:18:24Z" + generated_at: "2026-04-25T12:43:13Z" model: gpt-5.4 provider: openai - source_hash: f0db8300a2a1b8367faca0aa1a857d67c06723eb4170e86440f827a802d05a34 + source_hash: c8352a695890b2bef8d15337c6371f33363222ec371f91dd0e6a8ba84cccbbc8 source_path: help/testing.md workflow: 15 --- @@ -18,7 +18,7 @@ OpenClaw має три набори Vitest (unit/integration, e2e, live) і не Docker-ранерів. Цей документ — посібник «як ми тестуємо»: - Що охоплює кожен набір (і що він навмисно _не_ охоплює). -- Які команди запускати для типових сценаріїв (локально, перед push, налагодження). +- Які команди запускати для типових сценаріїв роботи (локально, перед push, налагодження). - Як live-тести знаходять облікові дані та вибирають моделі/провайдерів. - Як додавати регресійні тести для реальних проблем із моделями/провайдерами. @@ -28,188 +28,188 @@ Docker-ранерів. Цей документ — посібник «як ми - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` - Швидший локальний запуск повного набору на потужній машині: `pnpm test:max` -- Прямий цикл Vitest watch: `pnpm test:watch` +- Прямий цикл спостереження Vitest: `pnpm test:watch` - Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Під час ітерацій над однією помилкою спочатку віддавайте перевагу точковим запускам. +- Під час ітерації над однією помилкою спочатку віддавайте перевагу цільовим запускам. - QA-сайт на базі Docker: `pnpm qa:lab:up` - QA-lane на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Коли ви змінюєте тести або хочете додаткової впевненості: +Коли ви змінюєте тести або хочете більшої впевненості: - Gate покриття: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` -Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): +Під час налагодження реальних провайдерів/моделей (потрібні справжні облікові дані): -- Live-набір (моделі + перевірки інструментів/зображень Gateway): `pnpm test:live` -- Точково запустити один live-файл у тихому режимі: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Docker-прогін live-моделей: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер запускає текстовий хід, а також невелику перевірку у стилі читання файлу. - Моделі, чиї метадані вказують вхід `image`, також запускають невеликий хід із зображенням. - Вимкніть додаткові перевірки за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або +- Набір live (моделі + probes інструментів/зображень Gateway): `pnpm test:live` +- Тихо націлитися на один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Docker sweep live-моделей: `pnpm test:docker:live-models` + - Кожна вибрана модель тепер виконує текстовий хід плюс невеликий probe у стилі читання файлу. + Моделі, чиї метадані оголошують вхід `image`, також виконують невеликий хід із зображенням. + Вимкніть додаткові probes за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера. - Покриття в CI: щоденні `OpenClaw Scheduled Live And E2E Checks` і ручні - `OpenClaw Release Checks` обидва викликають повторно використовуваний live/E2E workflow з - `include_live_suites: true`, який включає окремі матричні job-и Docker live model, - розбиті за провайдером. - - Для точкових повторних запусків у CI вручну запускайте `OpenClaw Live And E2E Checks (Reusable)` + `OpenClaw Release Checks` обидва викликають повторно використовуваний workflow live/E2E з + `include_live_suites: true`, який включає окремі Docker matrix jobs live-моделей, + розшардовані за провайдером. + - Для точкових повторних запусків у CI запускайте `OpenClaw Live And E2E Checks (Reusable)` з `include_live_suites: true` і `live_models_only: true`. - - Додавайте нові високосигнальні секрети провайдерів у `scripts/ci-hydrate-live-auth.sh`, а також у - `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` і його виклики - зі schedule/release. -- Димовий тест native Codex bound-chat: `pnpm test:docker:live-codex-bind` - - Запускає Docker live lane проти шляху Codex app-server, прив’язує синтетичний - Slack DM через `/codex bind`, виконує `/codex fast` і - `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення із зображенням - проходять через native plugin binding, а не через ACP. -- Димовий тест команди порятунку Crestodian: `pnpm test:live:crestodian-rescue-channel` - - Opt-in belt-and-suspenders перевірка поверхні команди порятунку message-channel. - Вона виконує `/crestodian status`, ставить у чергу зміну persistent model, + - Додавайте нові високосигнальні секрети провайдерів у `scripts/ci-hydrate-live-auth.sh` + а також у `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` та його + виклики за розкладом/для релізу. +- Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind` + - Запускає Docker live-lane проти шляху Codex app-server, прив’язує синтетичний + Slack DM за допомогою `/codex bind`, виконує `/codex fast` і + `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення зображення + проходять через native binding Plugin, а не через ACP. +- Smoke для rescue-команди Crestodian: `pnpm test:live:crestodian-rescue-channel` + - Опційна додаткова перевірка поверхні rescue-команди каналу повідомлень. + Вона виконує `/crestodian status`, ставить у чергу постійну зміну моделі, відповідає `/crestodian yes` і перевіряє шлях запису audit/config. -- Docker-димовий тест planner-а Crestodian: `pnpm test:docker:crestodian-planner` - - Запускає Crestodian у контейнері без конфігурації з підробленим Claude CLI у `PATH` - і перевіряє, що резервний fuzzy planner перетворюється на audited typed - config write. -- Docker-димовий тест першого запуску Crestodian: `pnpm test:docker:crestodian-first-run` - - Починає з порожнього каталогу стану OpenClaw, маршрутизує голий `openclaw` до - Crestodian, застосовує записи setup/model/agent/Discord plugin + SecretRef, - валідує конфігурацію та перевіряє записи аудиту. Той самий шлях налаштування Ring 0 +- Docker smoke планувальника Crestodian: `pnpm test:docker:crestodian-planner` + - Запускає Crestodian у контейнері без config із підробленим Claude CLI у `PATH` + і перевіряє, що нечіткий planner fallback перетворюється на audited typed + запис у config. +- Docker smoke першого запуску Crestodian: `pnpm test:docker:crestodian-first-run` + - Стартує з порожнього каталогу стану OpenClaw, маршрутизує голий `openclaw` до + Crestodian, застосовує записи setup/model/agent/Discord Plugin + SecretRef, + перевіряє config і перевіряє записи audit. Той самий шлях налаштування Ring 0 також покривається в QA Lab через `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. -- Димовий тест вартості Moonshot/Kimi: якщо задано `MOONSHOT_API_KEY`, запустіть +- Smoke вартості Moonshot/Kimi: якщо встановлено `MOONSHOT_API_KEY`, запустіть `openclaw models list --provider moonshot --json`, а потім виконайте ізольований `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` - проти `moonshot/kimi-k2.6`. Переконайтеся, що JSON показує Moonshot/K2.6 і що - транскрипт асистента зберігає нормалізоване `usage.cost`. + проти `moonshot/kimi-k2.6`. Переконайтеся, що JSON повідомляє про Moonshot/K2.6, а + transcript помічника зберігає нормалізований `usage.cost`. -Порада: коли вам потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через env-змінні allowlist, описані нижче. +Порада: коли вам потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через змінні середовища allowlist, описані нижче. -## Ранери для QA +## QA-специфічні ранери -Ці команди розташовані поруч з основними тестовими наборами, коли вам потрібен реалізм QA Lab: +Ці команди розташовані поруч з основними наборами тестів, коли вам потрібен реалізм QA Lab: -CI запускає QA Lab в окремих workflow. `Parity gate` запускається на відповідних PR -і при ручному запуску з mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на -`main` і вручну з mock parity gate, live Matrix lane та -керованим Convex live Telegram lane як паралельними job-ами. `OpenClaw Release Checks` -запускає ті самі lane-и перед погодженням релізу. +CI запускає QA Lab в окремих workflow. `Parity gate` запускається для відповідних PR і +при ручному dispatch із mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на +`main` і з ручного dispatch із mock parity gate, live Matrix lane та керованим Convex +live Telegram lane як паралельними jobs. `OpenClaw Release Checks` +запускає ті самі lanes перед затвердженням релізу. - `pnpm openclaw qa suite` - Запускає сценарії QA на базі репозиторію безпосередньо на хості. - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими - працівниками Gateway. Для `qa-channel` за замовчуванням використовується concurrency 4 - (обмежується кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати - кількість працівників, або `--concurrency 1` для старого послідовного lane. - - Завершується з ненульовим кодом, якщо будь-який сценарій зазнає невдачі. Використовуйте `--allow-failures`, якщо + worker-ами Gateway. `qa-channel` за замовчуванням має concurrency 4 (обмежену + кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати + кількість worker-ів, або `--concurrency 1` для старішого послідовного lane. + - Завершується з ненульовим кодом, якщо будь-який сценарій завершується невдачею. Використовуйте `--allow-failures`, коли вам потрібні артефакти без коду завершення з помилкою. - Підтримує режими провайдерів `live-frontier`, `mock-openai` і `aimock`. `aimock` запускає локальний сервер провайдера на базі AIMock для експериментального - покриття фікстур і protocol-mock без заміни lane `mock-openai`, - орієнтованого на сценарії. + покриття fixture і protocol-mock, не замінюючи + lane `mock-openai`, орієнтований на сценарії. - `pnpm openclaw qa suite --runner multipass` - - Запускає той самий QA-набір усередині тимчасової Linux VM Multipass. + - Запускає той самий QA suite всередині тимчасової Linux VM Multipass. - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на хості. - Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`. - - Для live-запусків передає підтримувані вхідні дані автентифікації QA, які практично - використовувати в гостьовій системі: - ключі провайдера через env, шлях до конфігурації QA live provider і `CODEX_HOME`, якщо він заданий. + - Live-запуски пересилають підтримувані вхідні дані автентифікації QA, які практично передати в гостьову систему: + ключі провайдерів через env, шлях до config live-провайдера QA і `CODEX_HOME`, + якщо він присутній. - Каталоги виводу мають залишатися під коренем репозиторію, щоб гостьова система могла записувати назад через - змонтовану робочу область. - - Записує звичайний QA-звіт і summary, а також журнали Multipass у + змонтований робочий простір. + - Записує звичайний QA report + summary, а також логи Multipass у `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Запускає QA-сайт на базі Docker для QA-роботи в операторському стилі. + - Запускає QA-сайт на базі Docker для операторського QA. - `pnpm test:docker:npm-onboard-channel-agent` - - Збирає npm tarball з поточного checkout, глобально встановлює його в - Docker, виконує неінтерактивний onboarding з ключем OpenAI API, типово налаштовує - Telegram, перевіряє, що ввімкнення plugin встановлює runtime-залежності на вимогу, + - Збирає npm tarball із поточного checkout, глобально встановлює його в + Docker, виконує неінтерактивне onboarding із ключем OpenAI API, за замовчуванням налаштовує + Telegram, перевіряє, що ввімкнення Plugin встановлює runtime-залежності на вимогу, запускає doctor і виконує один локальний хід агента проти змоканого endpoint OpenAI. - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити той самий lane - пакетного встановлення з Discord. + встановлення з пакета з Discord. - `pnpm test:docker:npm-telegram-live` - - Встановлює опублікований пакет OpenClaw у Docker, виконує onboarding - для встановленого пакета, налаштовує Telegram через встановлений CLI, а потім повторно використовує - live Telegram QA lane з цим встановленим пакетом як Gateway SUT. + - Встановлює опублікований пакет OpenClaw у Docker, виконує onboarding встановленого пакета, + налаштовує Telegram через встановлений CLI, а потім повторно використовує + live Telegram QA lane з цим встановленим пакетом як SUT Gateway. - За замовчуванням використовується `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`. - Використовує ті самі env-облікові дані Telegram або джерело облікових даних Convex, що й - `pnpm openclaw qa telegram`. Для автоматизації CI/release задайте + `pnpm openclaw qa telegram`. Для автоматизації в CI/релізі встановіть `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` разом із `OPENCLAW_QA_CONVEX_SITE_URL` і секретом ролі. Якщо `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі Convex присутні в CI, Docker-обгортка автоматично вибирає Convex. - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільний `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цього lane. - - GitHub Actions надає цей lane як ручний workflow для мейнтейнерів + - У GitHub Actions цей lane доступний як ручний workflow для мейнтейнерів `NPM Telegram Beta E2E`. Він не запускається при merge. Workflow використовує - середовище `qa-live-shared` і оренди облікових даних Convex CI. + середовище `qa-live-shared` і оренду CI-облікових даних Convex. - `pnpm test:docker:bundled-channel-deps` - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, а потім вмикає bundled channel/plugin через редагування конфігурації. - - Перевіряє, що виявлення setup залишає відсутніми runtime-залежності - plugin, які не налаштовано, що перший налаштований запуск Gateway або doctor встановлює - runtime-залежності кожного bundled plugin на вимогу, і що другий рестарт не перевстановлює - залежності, які вже були активовані. - - Також установлює відомий старіший npm baseline, вмикає Telegram перед запуском - `openclaw update --tag ` і перевіряє, що doctor після оновлення в кандидата - виправляє bundled channel runtime dependencies без післявстановлювального - виправлення з боку harness. + з налаштованим OpenAI, а потім вмикає вбудовані channel/plugins через + редагування config. + - Перевіряє, що виявлення setup залишає runtime-залежності + неналаштованого Plugin відсутніми, перший налаштований запуск Gateway або doctor + встановлює runtime-залежності кожного вбудованого Plugin на вимогу, а другий перезапуск не + перевстановлює залежності, які вже були активовані. + - Також встановлює відому старішу npm-базову версію, вмикає Telegram перед запуском + `openclaw update --tag ` і перевіряє, що + post-update doctor кандидата відновлює runtime-залежності вбудованого channel без + side postinstall-відновлення з боку harness. - `pnpm test:parallels:npm-update` - - Запускає native packaged-install димовий тест оновлення через гостьові системи Parallels. Кожна - вибрана платформа спочатку встановлює потрібний baseline package, а потім запускає - встановлену команду `openclaw update` у тій самій гостьовій системі та перевіряє встановлену + - Запускає native smoke оновлення встановленого пакета в гостьових системах Parallels. Кожна + вибрана платформа спочатку встановлює запитаний базовий пакет, а потім виконує + команду встановленого `openclaw update` у тій самій гостьовій системі та перевіряє встановлену версію, статус оновлення, готовність gateway і один локальний хід агента. - - Використовуйте `--platform macos`, `--platform windows` або `--platform linux`, коли - ітеруєте лише одну гостьову систему. Використовуйте `--json` для шляху до summary artifact і + - Використовуйте `--platform macos`, `--platform windows` або `--platform linux`, коли ітеруєте + над однією гостьовою системою. Використовуйте `--json` для шляху до артефакту підсумку та статусу кожного lane. - - Обгортайте тривалі локальні запуски тайм-аутом хоста, щоб збої транспорту Parallels - не з’їли решту вікна тестування: + - Обгорніть довгі локальні запуски в host timeout, щоб збої транспорту Parallels + не поглинули решту вікна тестування: ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json ``` - - Скрипт записує вкладені журнали lane у `/tmp/openclaw-parallels-npm-update.*`. + - Скрипт записує вкладені логи lanes у `/tmp/openclaw-parallels-npm-update.*`. Перевіряйте `windows-update.log`, `macos-update.log` або `linux-update.log`, - перш ніж припускати, що зовнішня обгортка зависла. - - Оновлення Windows може витрачати 10–15 хвилин на post-update doctor/runtime - repair dependencies у холодній гостьовій системі; це все ще нормально, якщо вкладений + перш ніж вважати, що зовнішня обгортка зависла. + - Оновлення Windows може витрачати від 10 до 15 хвилин на post-update doctor/runtime + repair залежностей на холодній гостьовій системі; це все ще нормально, якщо вкладений npm debug log продовжує оновлюватися. - - Не запускайте цю агреговану обгортку паралельно з окремими димовими lane-ами Parallels - для macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати через - відновлення snapshot, роздачу пакетів або стан guest gateway. - - Доказ після оновлення запускає звичайну поверхню bundled plugin, оскільки - capability facades, як-от speech, image generation і media - understanding, завантажуються через bundled runtime API навіть тоді, коли сам + - Не запускайте цю агреговану обгортку паралельно з окремими smoke-lanes Parallels + для macOS, Windows або Linux. Вони використовують спільний стан VM і можуть конфліктувати під час + відновлення snapshot, роздачі пакетів або стану guest gateway. + - Post-update proof запускає звичайну поверхню bundled Plugin, тому що + фасади можливостей, як-от speech, image generation і media + understanding, завантажуються через bundled runtime API, навіть коли сам хід агента перевіряє лише просту текстову відповідь. - `pnpm openclaw qa aimock` - - Запускає лише локальний сервер провайдера AIMock для прямого димового - тестування протоколу. + - Запускає лише локальний сервер провайдера AIMock для прямого smoke-тестування протоколу. - `pnpm openclaw qa matrix` - - Запускає Matrix live QA lane проти тимчасового Tuwunel homeserver на базі Docker. + - Запускає live QA lane Matrix проти тимчасового homeserver Tuwunel на базі Docker. - Цей QA-хост наразі призначений лише для репозиторію/розробки. Пакетні встановлення OpenClaw не постачають `qa-lab`, тому вони не надають `openclaw qa`. - - Checkout-и репозиторію завантажують bundled runner безпосередньо; окремий крок - встановлення plugin не потрібен. - - Створює трьох тимчасових користувачів Matrix (`driver`, `sut`, `observer`) і одну приватну кімнату, а потім запускає дочірній QA gateway з реальним Matrix plugin як транспортом SUT. - - За замовчуванням використовує зафіксований стабільний образ Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Перевизначайте через `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, якщо потрібно протестувати інший образ. - - Matrix не надає спільних прапорців джерела облікових даних, оскільки lane створює тимчасових користувачів локально. - - Записує Matrix QA report, summary, observed-events artifact і об’єднаний журнал виводу stdout/stderr у `.artifacts/qa-e2e/...`. - - За замовчуванням виводить прогрес і примусово застосовує жорсткий тайм-аут виконання через `OPENCLAW_QA_MATRIX_TIMEOUT_MS` (типово 30 хвилин). Очищення обмежується `OPENCLAW_QA_MATRIX_CLEANUP_TIMEOUT_MS`, а у випадку збоїв додається команда відновлення `docker compose ... down --remove-orphans`. + - Checkout-и репозиторію завантажують вбудований runner напряму; окремий крок встановлення Plugin не потрібен. + - Створює трьох тимчасових користувачів Matrix (`driver`, `sut`, `observer`) плюс одну приватну кімнату, а потім запускає дочірній QA gateway із реальним Matrix Plugin як транспортом SUT. + - За замовчуванням використовує зафіксований стабільний образ Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Перевизначайте через `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, коли потрібно протестувати інший образ. + - Matrix не надає спільних прапорців джерела облікових даних, оскільки lane локально створює тимчасових користувачів. + - Записує звіт Matrix QA, summary, артефакт observed-events і комбінований лог виводу stdout/stderr у `.artifacts/qa-e2e/...`. + - За замовчуванням виводить прогрес і примусово обмежує час виконання через `OPENCLAW_QA_MATRIX_TIMEOUT_MS` (за замовчуванням 30 хвилин). Час cleanup обмежується `OPENCLAW_QA_MATRIX_CLEANUP_TIMEOUT_MS`, а збої містять команду відновлення `docker compose ... down --remove-orphans`. - `pnpm openclaw qa telegram` - - Запускає Telegram live QA lane проти реальної приватної групи, використовуючи токени ботів driver і SUT з env. + - Запускає live QA lane Telegram проти реальної приватної групи, використовуючи токени ботів driver і SUT з env. - Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Ідентифікатор групи має бути числовим Telegram chat id. - - Підтримує `--credential-source convex` для спільних пулів облікових даних. За замовчуванням використовуйте режим env або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. - - Завершується з ненульовим кодом, якщо будь-який сценарій зазнає невдачі. Використовуйте `--allow-failures`, якщо - вам потрібні артефакти без коду завершення з помилкою. + - Підтримує `--credential-source convex` для спільних пулінгових облікових даних. За замовчуванням використовуйте режим env або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути орендовані облікові дані з пулу. + - Завершується з ненульовим кодом, якщо будь-який сценарій завершується невдачею. Використовуйте `--allow-failures`, коли ви + хочете отримати артефакти без коду завершення з помилкою. - Потребує двох різних ботів в одній приватній групі, причому бот SUT має мати Telegram username. - Для стабільного спостереження bot-to-bot увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох ботів і переконайтеся, що бот driver може спостерігати трафік ботів у групі. - - Записує Telegram QA report, summary і observed-messages artifact у `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту на надсилання driver до спостережуваної відповіді SUT. + - Записує звіт Telegram QA, summary і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту на надсилання від driver до спостереженої відповіді SUT. -Live transport lane-и мають один стандартний контракт, щоб нові транспорти не розходилися: +Live transport lanes мають один спільний стандартний контракт, щоб нові транспорти не відхилялися: -`qa-channel` залишається широким синтетичним QA-набором і не входить до матриці покриття live transport. +`qa-channel` залишається широким синтетичним QA suite і не є частиною матриці покриття live +transport. | Lane | Canary | Mention gating | Allowlist block | Top-level reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | | -------- | ------ | -------------- | --------------- | --------------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | @@ -219,34 +219,34 @@ Live transport lane-и мають один стандартний контрак ### Спільні облікові дані Telegram через Convex (v1) Коли для `openclaw qa telegram` увімкнено `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`), -QA lab отримує ексклюзивну lease з пулу на базі Convex, надсилає heartbeat -цієї lease, поки lane працює, і звільняє lease під час завершення роботи. +QA lab отримує ексклюзивну оренду з пулу на базі Convex, надсилає Heartbeat +цієї оренди, поки lane виконується, і звільняє оренду під час завершення роботи. Еталонний scaffold проєкту Convex: - `qa/convex-credential-broker/` -Обов’язкові env-змінні: +Обов’язкові змінні середовища: -- `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` - Вибір ролі облікових даних: - CLI: `--credential-role maintainer|ci` - - Типове значення через env: `OPENCLAW_QA_CREDENTIAL_ROLE` (у CI типово `ci`, інакше `maintainer`) + - Значення env за замовчуванням: `OPENCLAW_QA_CREDENTIAL_ROLE` (у CI за замовчуванням `ci`, інакше `maintainer`) -Необов’язкові env-змінні: +Необов’язкові змінні середовища: -- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (типово `1200000`) -- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (типово `30000`) -- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (типово `90000`) -- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (типово `15000`) -- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (типово `/qa-credentials/v1`) +- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (за замовчуванням `1200000`) +- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (за замовчуванням `30000`) +- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (за замовчуванням `90000`) +- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (за замовчуванням `15000`) +- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (за замовчуванням `/qa-credentials/v1`) - `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов’язковий trace id) - `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` URL-и Convex лише для локальної розробки. -`OPENCLAW_QA_CONVEX_SITE_URL` у звичайному режимі роботи має використовувати `https://`. +У звичайному режимі `OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://`. Адміністративні команди мейнтейнера (додавання/видалення/перелік пулу) потребують саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. @@ -260,12 +260,12 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайта Convex, секрети broker, -endpoint prefix, HTTP timeout і доступність admin/list без виведення -значень секретів. Використовуйте `--json` для machine-readable виводу у скриптах і CI +Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайту Convex, секрети broker, +prefix endpoint, тайм-аут HTTP і досяжність admin/list, не виводячи +значення секретів. Використовуйте `--json` для машиночитаного виводу в скриптах і CI утилітах. -Контракт типового endpoint (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): +Контракт endpoint за замовчуванням (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` @@ -283,7 +283,7 @@ endpoint prefix, HTTP timeout і доступність admin/list без вив - `POST /admin/remove` (лише секрет maintainer) - Запит: `{ credentialId, actorId }` - Успіх: `{ status: "ok", changed, credential }` - - Захист активної lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` + - Захист активної оренди: `{ status: "error", code: "LEASE_ACTIVE", ... }` - `POST /admin/list` (лише секрет maintainer) - Запит: `{ kind?, status?, includePayload?, limit? }` - Успіх: `{ status: "ok", credentials, count }` @@ -292,57 +292,57 @@ endpoint prefix, HTTP timeout і доступність admin/list без вив - `{ groupId: string, driverToken: string, sutToken: string }` - `groupId` має бути рядком із числовим Telegram chat id. -- `admin/add` валідує цю форму для `kind: "telegram"` і відхиляє некоректні payload. +- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє некоректні payload. ### Додавання каналу до QA -Додавання каналу до markdown QA system вимагає рівно двох речей: +Додавання каналу до markdown-системи QA потребує рівно двох речей: -1. Транспортного адаптера для каналу. -2. Набору сценаріїв, що перевіряє контракт каналу. +1. Адаптера транспорту для каналу. +2. Пакета сценаріїв, який перевіряє контракт каналу. -Не додавайте новий кореневий QA-командний root верхнього рівня, якщо спільний хост `qa-lab` може -взяти цей потік на себе. +Не додавайте новий кореневий QA-командний root верхнього рівня, якщо спільний хост `qa-lab` +може керувати цим потоком. `qa-lab` відповідає за спільну механіку хоста: - root команди `openclaw qa` - запуск і завершення suite -- concurrency працівників +- concurrency worker-ів - запис артефактів - генерацію звітів - виконання сценаріїв - compatibility aliases для старіших сценаріїв `qa-channel` -Runner plugin-и відповідають за транспортний контракт: +Runner Plugins відповідають за транспортний контракт: - як `openclaw qa ` монтується під спільним root `qa` -- як gateway налаштовується для цього транспорту +- як Gateway налаштовується для цього транспорту - як перевіряється готовність -- як ін’єктуються вхідні події +- як інжектуються вхідні події - як спостерігаються вихідні повідомлення -- як надаються транскрипти та нормалізований стан транспорту +- як надаються transcripts і нормалізований стан транспорту - як виконуються дії на базі транспорту -- як обробляється transport-specific reset або cleanup +- як обробляється reset або cleanup, специфічний для транспорту -Мінімальний поріг прийняття для нового каналу: +Мінімальний поріг впровадження для нового каналу: 1. Залишайте `qa-lab` власником спільного root `qa`. -2. Реалізуйте transport runner на спільному seam хоста `qa-lab`. -3. Залишайте transport-specific механіку всередині runner plugin або harness каналу. -4. Монтуйте runner як `openclaw qa ` замість реєстрації конкуруючої root-команди. - Runner plugin-и мають оголошувати `qaRunners` у `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` з `runtime-api.ts`. - Залишайте `runtime-api.ts` легким; lazy CLI і виконання runner мають залишатися за окремими entrypoint-ами. +2. Реалізуйте runner транспорту на спільному seam хоста `qa-lab`. +3. Залишайте специфічну для транспорту механіку всередині runner Plugin або harness каналу. +4. Монтуйте runner як `openclaw qa `, а не реєструйте конкуруючий root command. + Runner Plugins мають оголошувати `qaRunners` у `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. + Тримайте `runtime-api.ts` легким; ліниве виконання CLI і runner має залишатися за окремими entrypoints. 5. Створюйте або адаптуйте markdown-сценарії в тематичних каталогах `qa/scenarios/`. -6. Використовуйте generic scenario helpers для нових сценаріїв. -7. Зберігайте працездатність наявних compatibility aliases, якщо тільки репозиторій не виконує навмисну міграцію. +6. Використовуйте generic helpers для нових сценаріїв. +7. Зберігайте працездатність наявних compatibility aliases, якщо в репозиторії не відбувається навмисна міграція. Правило прийняття рішення суворе: - Якщо поведінку можна один раз виразити в `qa-lab`, розміщуйте її в `qa-lab`. -- Якщо поведінка залежить від одного channel transport, залишайте її в цьому runner plugin або harness plugin. -- Якщо сценарію потрібна нова можливість, яку може використовувати більше ніж один канал, додайте generic helper замість channel-specific гілки в `suite.ts`. -- Якщо поведінка має сенс лише для одного транспорту, залишайте сценарій transport-specific і явно зазначайте це в контракті сценарію. +- Якщо поведінка залежить від одного транспорту каналу, залишайте її в тому runner Plugin або harness Plugin. +- Якщо сценарію потрібна нова можливість, яку може використовувати більше ніж один канал, додавайте generic helper замість специфічної для каналу гілки в `suite.ts`. +- Якщо поведінка має сенс лише для одного транспорту, залишайте сценарій специфічним для цього транспорту й явно відображайте це в контракті сценарію. Бажані назви generic helper для нових сценаріїв: @@ -368,21 +368,21 @@ Compatibility aliases залишаються доступними для ная - `resetBus` Нова робота над каналами має використовувати generic helper names. -Compatibility aliases існують, щоб уникнути міграції типу flag day, а не як модель для +Compatibility aliases існують, щоб уникнути міграції в один день, а не як модель для створення нових сценаріїв. ## Набори тестів (що де запускається) -Сприймайте набори як «зростання реалізму» (і зростання flaky/cost): +Думайте про набори як про «зростання реалістичності» (і зростання нестабільності/вартості): -### Unit / integration (типово) +### Unit / integration (за замовчуванням) - Команда: `pnpm test` -- Конфігурація: неточкові запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shard-и в per-project configs для паралельного планування -- Файли: inventories core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і внесені до allowlist node-тести `ui`, які покриває `vitest.unit.config.ts` +- Config: нетаргетовані запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shards у конфіги для кожного проєкту для паралельного планування +- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і whitelist node-тестів `ui`, охоплених `vitest.unit.config.ts` - Обсяг: - - Чисті модульні тести - - In-process інтеграційні тести (автентифікація gateway, маршрутизація, tooling, парсинг, конфігурація) + - Чисті unit-тести + - In-process integration-тести (автентифікація gateway, маршрутизація, tooling, parsing, config) - Детерміновані регресії для відомих багів - Очікування: - Запускається в CI @@ -390,94 +390,94 @@ Compatibility aliases існують, щоб уникнути міграції - Має бути швидким і стабільним - + - - Неточкові запуски `pnpm test` використовують дванадцять менших shard-конфігів (`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 process. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension витісняти не пов’язані набори. - - `pnpm test --watch` усе ще використовує native root-граф проєктів `vitest.config.ts`, оскільки цикл watch із багатьма shard-ами є непрактичним. - - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спочатку маршрутизують явні цілі файлів/каталогів через scoped lane-и, тож `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості запуску root project. - - `pnpm test:changed` розгортає змінені git-шляхи в ті самі scoped lane-и, коли diff зачіпає лише маршрутизовні файли source/test; редагування config/setup усе ще повертаються до широкого повторного запуску root project. - - `pnpm check:changed` — це звичайний smart local gate для вузьких змін. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata і tooling, а потім запускає відповідні lane-и typecheck/lint/test. Зміни публічного Plugin SDK і plugin-contract включають один validation pass для extension, оскільки extensions залежать від цих контрактів core. Зміни версій лише в release metadata запускають точкові перевірки version/config/root-dependency замість повного набору, із захистом, який відхиляє зміни пакета поза полем версії верхнього рівня. - - Unit-тести з легкими імпортами з agents, commands, plugins, helper-ів auto-reply, `plugin-sdk` та подібних суто утилітних областей маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lane-ах. - - Вибрані helper source-файли `plugin-sdk` і `commands` також зіставляють запуски в changed mode з явними sibling test-ами в цих легких lane-ах, тож редагування helper-ів не змушують повторно запускати весь важкий набір для цього каталогу. - - `auto-reply` має три окремі bucket-и: helper-и core верхнього рівня, інтеграційні тести `reply.*` верхнього рівня та піддерево `src/auto-reply/reply/**`. Це не дає найважчій роботі harness-а reply потрапляти в дешеві тести status/chunk/token. + - Нетаргетований `pnpm test` запускає дванадцять менших shard-конфігів (`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 process. Це знижує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати не пов’язані набори. + - `pnpm test --watch` усе ще використовує native root граф проєкту `vitest.config.ts`, тому що цикл watch із багатьма shards непрактичний. + - `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, коли diff торкається лише routable source/test файлів; редагування config/setup усе ще повертаються до широкого повторного запуску root-project. + - `pnpm check:changed` — це звичайний розумний локальний gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata і tooling, а потім запускає відповідні lanes typecheck/lint/test. Зміни в публічному Plugin SDK і plugin-contract включають один прохід перевірки extension, тому що extensions залежать від цих контрактів core. Оновлення версій лише в release metadata запускають цільові перевірки version/config/root-dependency замість повного набору, із захистом, який відхиляє зміни пакетів поза полем version верхнього рівня. + - Легкі за імпортами unit-тести з agents, commands, plugins, helper-ів auto-reply, `plugin-sdk` і подібних чистих утилітних ділянок маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; файли зі станом/важкі за runtime залишаються на наявних lanes. + - Вибрані helper source-файли `plugin-sdk` і `commands` також зіставляють запуски в режимі changed з явними сусідніми тестами в цих легких lanes, тому редагування helper-ів уникає повторного запуску повного важкого набору для цього каталогу. + - `auto-reply` має три окремі buckets: helper-и core верхнього рівня, integration-тести верхнього рівня `reply.*` і піддерево `src/auto-reply/reply/**`. Це утримує найважчу роботу harness reply поза дешевими тестами status/chunk/token. - - Коли ви змінюєте вхідні дані виявлення message-tool або runtime-контекст compaction, - зберігайте обидва рівні покриття. - - Додавайте сфокусовані helper-регресії для чистих меж маршрутизації та - нормалізації. - - Підтримуйте в доброму стані інтеграційні набори embedded runner: + - Коли ви змінюєте вхідні дані виявлення message-tool або runtime + контекст 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 id і поведінка Compaction все ще проходять - через реальні шляхи `run.ts` / `compact.ts`; тести лише для helper-ів - не є достатньою заміною цих інтеграційних шляхів. + - Ці набори перевіряють, що scoped id та поведінка compaction і надалі проходять + через реальні шляхи `run.ts` / `compact.ts`; лише helper-тести + не є достатньою заміною для цих integration-шляхів. - + - - Базова конфігурація Vitest типово використовує `threads`. - - Спільна конфігурація Vitest фіксує `isolate: false` і використовує - non-isolated runner у root projects, e2e і live configs. - - Root lane UI зберігає свої `jsdom` setup і optimizer, але теж працює на - спільному non-isolated runner. - - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` - зі спільної конфігурації Vitest. - - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх Node-процесів Vitest, - щоб зменшити churn компіляції V8 під час великих локальних запусків. - Задайте `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною + - Базовий config Vitest за замовчуванням використовує `threads`. + - Спільний config Vitest фіксує `isolate: false` і використовує + неізольований runner у root projects, e2e та live configs. + - Root lane UI зберігає свій `jsdom` setup і optimizer, але також працює на + спільному неізольованому runner. + - Кожен shard `pnpm test` успадковує ті самі значення за замовчуванням `threads` + `isolate: false` + зі спільного config Vitest. + - `scripts/run-vitest.mjs` за замовчуванням додає `--no-maglev` для дочірніх Node + process-ів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. + Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. - + - - `pnpm changed:lanes` показує, які архітектурні lane-и запускає diff. - - Хук pre-commit виконує лише форматування. Він повторно індексує відформатовані файли і + - `pnpm changed:lanes` показує, які архітектурні lanes запускає diff. + - Pre-commit hook виконує лише форматування. Він повторно додає відформатовані файли до staging і не запускає lint, typecheck або тести. - Явно запускайте `pnpm check:changed` перед передачею або push, коли вам - потрібен smart local gate. Зміни публічного Plugin SDK і plugin-contract - включають один validation pass для extension. - - `pnpm test:changed` маршрутизує через scoped lane-и, коли змінені шляхи - чисто зіставляються з меншим набором. + потрібен розумний локальний gate. Зміни в публічному Plugin SDK і plugin-contract + включають один прохід перевірки extension. + - `pnpm test:changed` маршрутизує через scoped lanes, коли змінені шляхи + чисто відображаються на менший набір. - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, - лише з вищим лімітом працівників. - - Автомасштабування локальних працівників навмисно консервативне й зменшує навантаження, - коли середнє навантаження хоста вже високе, тож кілька одночасних - запусків Vitest типово завдають менше шкоди. - - Базова конфігурація Vitest позначає проєкти/конфіг-файли як - `forceRerunTriggers`, щоб повторні запуски в changed mode залишалися коректними, - коли змінюється wiring тестів. - - Конфігурація зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних - хостах; задайте `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете + лише з вищим лімітом worker-ів. + - Автомасштабування локальних worker-ів навмисно консервативне і знижує навантаження, + коли середнє навантаження хоста вже високе, тому кілька одночасних + запусків Vitest за замовчуванням завдають менше шкоди. + - Базовий config Vitest позначає файли projects/config як + `forceRerunTriggers`, щоб повторні запуски в режимі changed залишалися коректними, коли змінюється + зв’язування тестів. + - Config зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на + підтримуваних хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання. - - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпорту, а також - вивід розбивки імпортів. - - `pnpm test:perf:imports:changed` обмежує той самий профілювальний вигляд + - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпорту плюс + вивід breakdown імпортів. + - `pnpm test:perf:imports:changed` обмежує той самий вид профілювання файлами, зміненими відносно `origin/main`. - Коли один гарячий тест усе ще витрачає більшість часу на стартові імпорти, тримайте важкі залежності за вузьким локальним seam `*.runtime.ts` і - напряму мокайте цей seam замість глибоких імпортів runtime helper-ів лише для того, - щоб передати їх через `vi.mock(...)`. + напряму мокайте цей seam замість глибокого імпорту helper-ів runtime + лише для того, щоб передати їх у `vi.mock(...)`. - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований - `test:changed` з native root-project path для цього закоміченого diff і виводить - wall time плюс macOS max RSS. + `test:changed` із native шляхом root-project для цього зафіксованого + diff і виводить wall time плюс max RSS на macOS. - `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного брудного дерева, маршрутизуючи список змінених файлів через - `scripts/test-projects.mjs` і root-конфіг Vitest. - - `pnpm test:perf:profile:main` записує CPU-профіль main thread для - накладних витрат запуску і transform у Vitest/Vite. - - `pnpm test:perf:profile:runner` записує CPU+heap профілі runner-а для + `scripts/test-projects.mjs` і root config Vitest. + - `pnpm test:perf:profile:main` записує CPU profile головного потоку для + накладних витрат запуску та трансформації Vitest/Vite. + - `pnpm test:perf:profile:runner` записує CPU+heap profiles runner для unit-набору з вимкненим паралелізмом файлів. @@ -486,246 +486,246 @@ Compatibility aliases існують, щоб уникнути міграції ### Stability (Gateway) - Команда: `pnpm test:stability:gateway` -- Конфігурація: `vitest.gateway.config.ts`, примусово один працівник +- Config: `vitest.gateway.config.ts`, примусово один worker - Обсяг: - - Запускає реальний loopback Gateway з увімкненою діагностикою за замовчуванням - - Пропускає синтетичну churn-активність повідомлень gateway, пам’яті та великих payload через шлях діагностичних подій - - Виконує запити до `diagnostics.stability` через Gateway WS RPC + - Запускає реальний loopback Gateway з діагностикою, увімкненою за замовчуванням + - Проганяє синтетичне churn повідомлень gateway, пам’яті та великих payload через шлях діагностичних подій + - Виконує запити до `diagnostics.stability` через WS RPC Gateway - Покриває helper-и збереження diagnostic stability bundle - - Перевіряє, що recorder залишається обмеженим, синтетичні зразки RSS залишаються в межах budget тиску, а глибини черг на рівні сесій знову спадають до нуля + - Перевіряє, що recorder залишається обмеженим, синтетичні вибірки RSS залишаються в межах бюджету навантаження, а глибини черг на сесію повертаються до нуля - Очікування: - - Безпечно для CI і без ключів - - Вузький lane для подальшої перевірки регресій стабільності, а не заміна повного набору Gateway + - Безпечний для CI і без ключів + - Вузький lane для подальшої роботи над регресіями stability, а не заміна повного набору Gateway -### E2E (димовий тест Gateway) +### E2E (Gateway smoke) - Команда: `pnpm test:e2e` -- Конфігурація: `vitest.e2e.config.ts` -- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled plugin під `extensions/` +- Config: `vitest.e2e.config.ts` +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled Plugin у `extensions/` - Типові значення runtime: - - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. - - Використовує адаптивну кількість працівників (CI: до 2, локально: типово 1). - - За замовчуванням працює в silent mode, щоб зменшити накладні витрати консолі I/O. + - Використовує Vitest `threads` з `isolate: false`, узгоджено з рештою репозиторію. + - Використовує адаптивну кількість worker-ів (CI: до 2, локально: 1 за замовчуванням). + - За замовчуванням запускається в silent mode, щоб зменшити накладні витрати на I/O консолі. - Корисні перевизначення: - - `OPENCLAW_E2E_WORKERS=`, щоб примусово задати кількість працівників (максимум 16). - - `OPENCLAW_E2E_VERBOSE=1`, щоб знову ввімкнути докладний вивід у консоль. + - `OPENCLAW_E2E_WORKERS=` щоб примусово задати кількість worker-ів (обмежено 16). + - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний вивід у консоль. - Обсяг: - - End-to-end поведінка Gateway з кількома екземплярами - - Поверхні WebSocket/HTTP, спарювання Node і важчий мережевий стек + - End-to-end поведінка gateway з кількома екземплярами + - Поверхні WebSocket/HTTP, pairing Node і більш важка мережева взаємодія - Очікування: - Запускається в CI (коли ввімкнено в pipeline) - - Реальні ключі не потрібні - - Має більше рухомих частин, ніж unit-тести (може бути повільнішим) + - Не потребує реальних ключів + - Більше рухомих частин, ніж у unit-тестах (може бути повільнішим) -### E2E: димовий тест бекенду OpenShell +### E2E: smoke backend OpenShell - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` - Обсяг: - - Запускає ізольований OpenShell Gateway на хості через Docker - - Створює sandbox з тимчасового локального Dockerfile - - Перевіряє бекенд OpenShell в OpenClaw через реальні `sandbox ssh-config` + SSH exec - - Перевіряє remote-canonical поведінку файлової системи через fs bridge sandbox + - Запускає ізольований Gateway OpenShell на хості через Docker + - Створює sandbox із тимчасового локального Dockerfile + - Перевіряє backend OpenShell OpenClaw через реальні `sandbox ssh-config` + SSH exec + - Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge - Очікування: - - Лише за opt-in; не входить до типового запуску `pnpm test:e2e` + - Лише опційний запуск; не є частиною типового запуску `pnpm test:e2e` - Потребує локального CLI `openshell` і працездатного Docker daemon - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий gateway і sandbox - Корисні перевизначення: - - `OPENCLAW_E2E_OPENSHELL=1`, щоб увімкнути тест під час ручного запуску ширшого e2e-набору - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, щоб указати нестандартний CLI binary або wrapper script + - `OPENCLAW_E2E_OPENSHELL=1` щоб увімкнути тест під час ручного запуску ширшого набору e2e + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб указати нестандартний бінарний файл CLI або wrapper script ### Live (реальні провайдери + реальні моделі) - Команда: `pnpm test:live` -- Конфігурація: `vitest.live.config.ts` -- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести bundled plugin під `extensions/` -- Типово: **увімкнено** через `pnpm test:live` (задає `OPENCLAW_LIVE_TEST=1`) +- Config: `vitest.live.config.ts` +- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести bundled Plugin у `extensions/` +- За замовчуванням: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) - Обсяг: - - «Чи справді цей провайдер/модель _сьогодні_ працює з реальними обліковими даними?» - - Виявлення змін формату провайдера, особливостей tool calling, проблем автентифікації та поведінки rate limit + - «Чи справді цей провайдер/модель працює _сьогодні_ з реальними обліковими даними?» + - Виявлення змін форматів провайдерів, особливостей виклику інструментів, проблем автентифікації та поведінки rate limit - Очікування: - - За задумом нестабільний для CI (реальні мережі, реальні політики провайдерів, квоти, outages) - - Коштує грошей / використовує rate limits + - Навмисно нестабільні для CI (реальні мережі, реальні політики провайдерів, квоти, збої) + - Коштують грошей / використовують rate limits - Краще запускати звужені підмножини, а не «все» -- Live-запуски підтягують `~/.profile`, щоб підхопити відсутні API-ключі. -- За замовчуванням live-запуски все ще ізолюють `HOME` і копіюють матеріали config/auth у тимчасовий test home, щоб unit-фікстури не могли змінити ваш реальний `~/.openclaw`. -- Задавайте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли навмисно хочете, щоб live-тести використовували ваш реальний домашній каталог. -- `pnpm test:live` тепер типово працює в тихішому режимі: він зберігає вивід прогресу `[live] ...`, але пригнічує додаткове повідомлення `~/.profile` і заглушує bootstrap-журнали gateway/шум Bonjour. Задайте `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете знову побачити повні стартові журнали. -- Ротація API-ключів (залежно від провайдера): задавайте `*_API_KEYS` у форматі через кому/крапку з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або перевизначення для live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях із rate limit. -- Вивід прогресу/heartbeat: - - Live-набори тепер виводять рядки прогресу в stderr, тож довгі виклики провайдерів помітно активні навіть тоді, коли перехоплення консолі Vitest тихе. - - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, тож рядки прогресу провайдера/gateway одразу транслюються під час live-запусків. +- Live-запуски використовують `~/.profile`, щоб підхопити відсутні API-ключі. +- За замовчуванням live-запуски все ще ізолюють `HOME` і копіюють матеріали config/auth у тимчасовий test home, щоб unit-fixtures не могли змінити ваш реальний `~/.openclaw`. +- Установлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли ви навмисно хочете, щоб live-тести використовували ваш реальний домашній каталог. +- `pnpm test:live` тепер за замовчуванням працює в тихішому режимі: зберігає вивід прогресу `[live] ...`, але приховує додаткове повідомлення про `~/.profile` і вимикає логи bootstrap Gateway/шум Bonjour. Установіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні стартові логи. +- Ротація API-ключів (залежно від провайдера): установіть `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або використовуйте перевизначення для live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях про rate limit. +- Вивід progress/heartbeat: + - Live-набори тепер виводять рядки прогресу в stderr, щоб довгі виклики провайдера залишалися видимо активними, навіть коли перехоплення консолі Vitest працює тихо. + - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, тому рядки прогресу провайдера/gateway транслюються негайно під час live-запусків. - Налаштовуйте 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 / pairing: додайте `pnpm test:e2e` +- Налагоджуєте «мій бот не працює» / специфічні збої провайдера / виклик інструментів: запускайте звужений `pnpm test:live` -## Live-тести (із мережевими зверненнями) +## Live-тести (що торкаються мережі) -Для матриці live-моделей, димових тестів бекенду CLI, димових тестів ACP, harness-а -Codex app-server і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, image, -music, video, media harness) — а також для обробки облікових даних під час live-запусків — див. -[Тестування — live-набори](/uk/help/testing-live). +Для live-матриці моделей, smoke-тестів backend CLI, smoke-тестів ACP, harness +Codex app-server і всіх live-тестів media-провайдерів (Deepgram, BytePlus, ComfyUI, image, +music, video, media harness) — а також обробки облікових даних для live-запусків — див. +[Тестування — live suites](/uk/help/testing-live). ## Docker-ранери (необов’язкові перевірки «працює в Linux») -Ці Docker-ранери поділяються на дві категорії: +Ці Docker-ранери поділяються на дві групи: -- Docker-ранери live-моделей: `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 і робочу область (і підтягують `~/.profile`, якщо він змонтований). Відповідні локальні entrypoint-и: `test:live:models-profiles` і `test:live:gateway-profiles`. -- Docker live runner-и типово використовують менший smoke cap, щоб повний Docker-прогін залишався практичним: - `test:docker:live-models` типово використовує `OPENCLAW_LIVE_MAX_MODELS=12`, а +- Docker-ранери live-моделей: `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 і робочий простір (а також підвантажують `~/.profile`, якщо його змонтовано). Відповідні локальні entrypoints: `test:live:models-profiles` і `test:live:gateway-profiles`. +- Docker-ранери live за замовчуванням мають менший 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-змінні, коли - навмисно хочете більший вичерпний прогін. -- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, а потім повторно використовує його для Docker live lane-ів. Він також збирає один спільний образ `scripts/e2e/Dockerfile` через `test:docker:e2e-build` і повторно використовує його для E2E container smoke runner-ів, які перевіряють зібраний застосунок. Агрегат використовує ваговий локальний планувальник: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує слотами процесів, а обмеження ресурсів не дозволяють одночасно стартувати всім важким live, npm-install і multi-service lane-ам. Типові значення — 10 слотів, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker-хост має більший запас ресурсів. Runner типово виконує Docker preflight, видаляє застарілі OpenClaw E2E-контейнери, виводить статус кожні 30 секунд, зберігає таймінги успішних lane-ів у `.artifacts/docker-tests/lane-timings.json` і використовує ці таймінги, щоб у наступних запусках спочатку стартували довші lane-и. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб вивести ваговий маніфест lane-ів без збирання або запуску Docker. -- Container smoke runner-и: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` підіймають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці змінні середовища, коли + вам явно потрібне більше, вичерпне сканування. +- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, а потім повторно використовує його для Docker live-lanes. Він також збирає один спільний образ `scripts/e2e/Dockerfile` через `test:docker:e2e-build` і повторно використовує його для smoke-ранерів E2E у контейнерах, які перевіряють уже зібраний застосунок. Агрегат використовує зважений локальний планувальник: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує слотами process-ів, а resource caps не дозволяють усім важким live-, npm-install- і multi-service-lanes стартувати одночасно. За замовчуванням це 10 слотів, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker-хост має більше запасу ресурсів. Ранер за замовчуванням виконує Docker preflight, видаляє застарілі контейнери OpenClaw E2E, виводить статус кожні 30 секунд, зберігає час виконання успішних lanes у `.artifacts/docker-tests/lane-timings.json` і використовує ці timings, щоб у наступних запусках спочатку стартували довші lanes. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб вивести зважений маніфест lanes без збирання або запуску Docker. +- Smoke-ранери контейнерів: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` запускають один або кілька реальних контейнерів і перевіряють integration-шляхи вищого рівня. -Docker-ранери live-моделей також bind-mount-ять лише потрібні CLI auth home-и (або всі підтримувані, якщо запуск не звужено), а потім копіюють їх у домашній каталог контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без зміни auth store хоста: +Docker-ранери live-моделей також bind-mount лише потрібні каталоги автентифікації CLI (або всі підтримувані, якщо запуск не звужено), а потім копіюють їх у домашній каталог контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени, не змінюючи auth store хоста: - Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) -- Димовий тест ACP bind: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`) -- Димовий тест CLI backend: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) -- Димовий тест harness-а Codex app-server: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) +- Smoke ACP bind: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; за замовчуванням охоплює Claude, Codex і Gemini, зі строгим покриттям OpenCode через `pnpm test:docker:live-acp-bind:opencode`) +- Smoke CLI backend: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) +- Smoke harness Codex app-server: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) - Gateway + dev agent: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) -- Open WebUI live smoke: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Live smoke Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) - Майстер onboarding (TTY, повний scaffolding): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) -- Димовий тест npm tarball onboarding/channel/agent: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через onboarding з env-ref плюс типово Telegram, перевіряє, що doctor відновлює runtime deps активованого plugin, і запускає один змоканий хід агента OpenAI. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте host rebuild через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемикайте канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Димовий тест глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, установлює його через `bun install -g` в ізольований home і перевіряє, що `openclaw infer image providers --json` повертає bundled image providers замість зависання. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте host build через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або копіюйте `dist/` із зібраного Docker-образу через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Installer Docker smoke: `bash scripts/test-install-sh-docker.sh` використовує один спільний npm cache для своїх root-, update- і direct-npm-контейнерів. Update smoke типово використовує npm `latest` як стабільний baseline перед оновленням до tarball кандидата. Перевірки installer-а без root зберігають ізольований npm cache, щоб записи cache, створені root, не маскували поведінку локального встановлення користувача. Задайте `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати cache root/update/direct-npm у локальних повторних запусках. +- Smoke onboarding/channel/agent через npm tarball: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через onboarding на основі env-ref плюс Telegram за замовчуванням, перевіряє, що doctor відновлює runtime deps активованого Plugin, і виконує один змоканий хід агента OpenAI. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть host rebuild через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або змініть канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Smoke глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольований home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих image providers замість зависання. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть host build через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` зі зібраного Docker-образу через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Docker smoke інсталятора: `bash scripts/test-install-sh-docker.sh` використовує один спільний npm cache для контейнерів root, update і direct-npm. Smoke оновлення за замовчуванням використовує npm `latest` як стабільну базову версію перед оновленням до tarball-кандидата. Перевірки інсталятора без root зберігають ізольований npm cache, щоб записи кешу, створені root, не маскували поведінку локального встановлення користувача. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати cache root/update/direct-npm між локальними повторними запусками. - Install Smoke у CI пропускає дубльований direct-npm global update через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. -- CLI smoke для видалення спільної робочої області агентів: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) типово збирає образ root Dockerfile, створює два агенти з однією робочою областю в ізольованому 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`. -- Мережа Gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) -- Регресія мінімального 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`, а потім примусово викликає відхилення provider schema і перевіряє, що сирий detail з’являється в журналах Gateway. -- Міст MCP channel (seeded Gateway + stdio bridge + raw Claude notification-frame smoke): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) -- Інструменти Pi bundle MCP (реальний stdio MCP server + smoke allow/deny для embedded Pi profile): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Очищення MCP для Cron/subagent (реальний Gateway + teardown дочірнього stdio MCP після ізольованих запусків cron і one-shot subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugin-и (install smoke + alias `/plugin` + семантика перезапуску Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) -- Димовий тест незмінного оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Димовий тест метаданих перезавантаження config: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) -- Runtime deps bundled plugin: `pnpm test:docker:bundled-channel-deps` типово збирає невеликий Docker-образ runner-а, один раз збирає та пакує OpenClaw на хості, а потім монтує цей tarball у кожний сценарій встановлення Linux. Повторно використовуйте образ через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропускайте host rebuild після свіжого локального build через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вказуйте на наявний tarball через `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний Docker-агрегат один раз попередньо пакує цей tarball, а потім розбиває перевірки bundled channel на незалежні lane-и, включно з окремими lane-ами оновлення для Telegram, Discord, Slack, Feishu, memory-lancedb і ACPX. Використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити матрицю channel під час прямого запуску bundled lane, або `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, щоб звузити сценарій оновлення. Lane також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` пригнічують відновлення doctor/runtime-dependency. -- Під час ітерацій звужуйте runtime deps bundled plugin, вимикаючи не пов’язані сценарії, наприклад: +- CLI smoke видалення спільного робочого простору агентів: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає root Dockerfile image, створює два агенти з одним workspace в ізольованому home контейнера, запускає `agents delete --json` і перевіряє коректний JSON плюс поведінку збереження workspace. Повторно використовуйте image install-smoke через `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Мережева взаємодія Gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) +- Мінімальна 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`, потім примусово викликає відхилення схеми провайдера та перевіряє, що raw detail з’являється в логах Gateway. +- Міст MCP channel (seeded Gateway + stdio bridge + raw smoke notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) +- Інструменти MCP набору Pi (реальний stdio MCP server + smoke allow/deny вбудованого профілю Pi): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Очищення MCP для Cron/subagent (реальний Gateway + teardown дочірнього stdio MCP після ізольованих запусків cron і одноразового subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (install smoke + alias `/plugin` + семантика перезапуску Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) +- Smoke незмінного оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke метаданих reload config: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) +- Runtime deps вбудованого Plugin: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий образ Docker runner, один раз збирає й пакує OpenClaw на хості, а потім монтує цей tarball у кожен сценарій встановлення Linux. Повторно використовуйте образ через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропустіть host rebuild після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть наявний tarball через `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний Docker-агрегат попередньо пакує цей tarball один раз, а потім розбиває перевірки bundled channel на незалежні lanes, включно з окремими lanes оновлення для Telegram, Discord, Slack, Feishu, memory-lancedb і ACPX. Використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити channel matrix під час прямого запуску bundled lane, або `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, щоб звузити сценарій оновлення. Lane також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` пригнічують відновлення doctor/runtime-dependency. +- Звужуйте runtime deps вбудованого Plugin під час ітерації, вимикаючи не пов’язані сценарії, наприклад: `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`. -Щоб вручну попередньо зібрати й повторно використовувати спільний образ built-app: +Щоб вручну попередньо зібрати та повторно використовувати спільний image зібраного застосунку: ```bash OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e:local pnpm test:docker:e2e-build OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Перевизначення образів для конкретних наборів, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, якщо задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти завантажують його, якщо він ще не локальний. Docker-тести QR та installer зберігають власні Dockerfile, оскільки вони перевіряють поведінку package/install, а не спільний runtime зібраного застосунку. +Перевизначення образів, специфічні для набору, такі як `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, якщо встановлені. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний image, скрипти завантажують його, якщо його ще немає локально. Docker-тести QR та інсталятора зберігають власні Dockerfile, оскільки вони перевіряють поведінку пакетування/встановлення, а не спільний runtime уже зібраного застосунку. -Docker-ранери live-моделей також bind-mount-ять поточний checkout у режимі лише для читання і +Docker-ранери live-моделей також монтують поточний checkout лише для читання і розміщують його в тимчасовому робочому каталозі всередині контейнера. Це зберігає runtime -образ компактним, водночас усе ще запускаючи Vitest проти ваших точних локальних source/config. -Крок staging пропускає великі локальні кеші та результати збірки застосунку, як-от -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні для застосунку каталоги `.build` або -виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання +image компактним, але все одно дозволяє запускати Vitest проти ваших точних локальних source/config. +Крок staging пропускає великі локальні кеші та результати збирання застосунку, такі як +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні для застосунків каталоги `.build` або +Gradle output, щоб Docker live-запуски не витрачали хвилини на копіювання артефактів, специфічних для машини. -Вони також задають `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали -реальні працівники каналів Telegram/Discord/etc. усередині контейнера. +Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб Gateway live probes не запускали +реальні worker-и каналів Telegram/Discord тощо всередині контейнера. `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте -`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити gateway +`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити Gateway live-покриття з цього Docker lane. -`test:docker:openwebui` — це smoke-перевірка сумісності вищого рівня: вона запускає -контейнер gateway OpenClaw з увімкненими HTTP endpoint OpenAI-compatible, -запускає зафіксований контейнер Open WebUI проти цього gateway, виконує вхід через -Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає -реальний chat-запит через проксі Open WebUI `/api/chat/completions`. +`test:docker:openwebui` — це smoke-тест сумісності вищого рівня: він запускає +контейнер Gateway OpenClaw з увімкненими HTTP endpoint, сумісними з OpenAI, +запускає прив’язаний контейнер Open WebUI проти цього gateway, виконує вхід через +Open WebUI, перевіряє, що `/api/models` надає `openclaw/default`, а потім надсилає +реальний запит чату через проксі Open WebUI `/api/chat/completions`. Перший запуск може бути помітно повільнішим, тому що Docker може знадобитися завантажити -образ Open WebUI, а Open WebUI може знадобитися завершити власне cold-start налаштування. -Цей lane очікує придатний ключ live-моделі, і `OPENCLAW_PROFILE_FILE` -(типово `~/.profile`) — основний спосіб надати його в Docker-ized запусках. +image Open WebUI, а самому Open WebUI — завершити власне cold-start налаштування. +Цей lane очікує придатний ключ live-моделі, а `OPENCLAW_PROFILE_FILE` +(`~/.profile` за замовчуванням) — основний спосіб надати його в Dockerized-запусках. Успішні запуски виводять невеликий JSON payload на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує -реального облікового запису Telegram, Discord або iMessage. Він запускає підготовлений Gateway -контейнер, стартує другий контейнер, який запускає `openclaw mcp serve`, а потім -перевіряє виявлення маршрутизованих розмов, читання транскриптів, метадані вкладень, -поведінку черги live-подій, маршрутизацію вихідного надсилання і channel + -permission-сповіщення у стилі Claude через реальний stdio MCP bridge. Перевірка сповіщень -безпосередньо аналізує сирі кадри stdio MCP, тож smoke-тест перевіряє те, що міст -справді надсилає, а не лише те, що випадково показує конкретний клієнтський SDK. +реального облікового запису Telegram, Discord або iMessage. Він запускає seed-ований контейнер +Gateway, стартує другий контейнер, який запускає `openclaw mcp serve`, а потім +перевіряє маршрутизоване виявлення розмов, читання transcript, метадані вкладень, +поведінку черги live-подій, маршрутизацію outbound send і сповіщення каналу + дозволів +у стилі Claude через реальний міст stdio MCP. Перевірка сповіщень +безпосередньо аналізує сирі кадри stdio MCP, тому smoke перевіряє те, що міст +справді надсилає, а не лише те, що випадково показує конкретний SDK клієнта. `test:docker:pi-bundle-mcp-tools` є детермінованим і не потребує ключа live-моделі. Він збирає Docker-образ репозиторію, запускає реальний stdio MCP probe server -усередині контейнера, матеріалізує цей сервер через embedded Pi bundle -MCP runtime, виконує інструмент, а потім перевіряє, що `coding` і `messaging` зберігають -інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх відфільтровують. +всередині контейнера, матеріалізує цей server через вбудований runtime Pi bundle +MCP, виконує інструмент, а потім перевіряє, що `coding` і `messaging` зберігають +інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. `test:docker:cron-mcp-cleanup` є детермінованим і не потребує ключа live-моделі. -Він запускає підготовлений Gateway з реальним stdio MCP probe server, виконує -ізольований хід Cron і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, +Він запускає seed-ований Gateway із реальним stdio MCP probe server, виконує +ізольований хід cron і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, що дочірній процес MCP завершується після кожного запуску. -Ручний ACP plain-language thread smoke (не CI): +Ручний smoke plain-language thread ACP (не для CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` - Зберігайте цей скрипт для сценаріїв регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації ACP thread, тому не видаляйте його. -Корисні env-змінні: +Корисні змінні середовища: -- `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`, щоб перевіряти лише env-змінні, підхоплені з `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 під `$HOME` монтуються в режимі лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед запуском тестів - - Типові каталоги: `.minimax` - - Типові файли: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Для звужених запусків провайдера монтуються лише потрібні каталоги/файли, визначені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Перевизначайте вручну через `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або список через кому, як-от `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` -- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, щоб звузити запуск -- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, щоб відфільтрувати провайдерів усередині контейнера -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків, яким не потрібне перевзбирання -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища profile (а не з env) -- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку gateway показує для smoke-тесту Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити nonce-check prompt, який використовує smoke-тест Open WebUI -- `OPENWEBUI_IMAGE=...`, щоб перевизначити зафіксований тег образу Open WebUI +- `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`, щоб перевіряти лише env vars, підвантажені з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги config/workspace і без монтування зовнішньої CLI-автентифікації +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI всередині Docker +- Зовнішні каталоги/файли CLI-автентифікації під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед стартом тестів + - Каталоги за замовчуванням: `.minimax` + - Файли за замовчуванням: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` + - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, визначені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` + - Перевизначайте вручну через `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або список через кому, наприклад `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` +- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` для звуження запуску +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` для фільтрації провайдерів усередині контейнера +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використовувати наявний image `openclaw:local-live` для повторних запусків, яким не потрібне повторне збирання +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища profile, а не з env +- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку gateway надає для smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити nonce-check prompt, який використовує smoke Open WebUI +- `OPENWEBUI_IMAGE=...`, щоб перевизначити прив’язаний тег image Open WebUI -## Перевірка docs +## Перевірка коректності документації -Після редагування docs запускайте перевірки docs: `pnpm check:docs`. -Запускайте повну перевірку anchor у Mintlify, коли вам також потрібні перевірки заголовків усередині сторінки: `pnpm docs:check-links:anchors`. +Після редагування документації запускайте перевірки docs: `pnpm check:docs`. +Запускайте повну перевірку anchor у Mintlify, коли вам також потрібні перевірки heading усередині сторінок: `pnpm docs:check-links:anchors`. ## Офлайн-регресія (безпечна для CI) Це регресії «реального pipeline» без реальних провайдерів: -- Виклик інструментів Gateway (mock OpenAI, реальний gateway + цикл агента): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує config + auth у примусовому режимі): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") +- Виклик інструментів Gateway (mock OpenAI, реальний цикл Gateway + agent): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує config + auth enforced): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") ## Оцінювання надійності агентів (Skills) У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агентів»: -- Mock tool-calling через реальний gateway + цикл агента (`src/gateway/gateway.test.ts`). -- Наскрізні потоки wizard, які перевіряють wiring сесії та ефекти конфігурації (`src/gateway/gateway.test.ts`). +- Mock tool-calling через реальний цикл Gateway + agent (`src/gateway/gateway.test.ts`). +- End-to-end потоки wizard, які перевіряють session wiring і вплив на config (`src/gateway/gateway.test.ts`). Що ще відсутнє для Skills (див. [Skills](/uk/tools/skills)): -- **Прийняття рішень:** коли Skills перелічено в prompt, чи вибирає агент правильний Skill (або уникає неактуальних)? -- **Дотримання вимог:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/аргументи? -- **Контракти workflow:** багатокрокові сценарії, що перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. +- **Decisioning:** коли Skills перелічено в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)? +- **Compliance:** чи читає агент `SKILL.md` перед використанням і чи виконує обов’язкові кроки/аргументи? +- **Workflow contracts:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. -Майбутні eval-и спочатку мають залишатися детермінованими: +Майбутні оцінювання спочатку мають залишатися детермінованими: -- Runner сценаріїв із mock-провайдерами для перевірки викликів інструментів + порядку, читання skill-файлів і wiring сесії. -- Невеликий набір сценаріїв, сфокусованих на skills (використовувати чи уникати, gating, prompt injection). -- Необов’язкові live eval-и (opt-in, із gate через env) лише після того, як з’явиться безпечний для CI набір. +- Runner сценаріїв із mock-провайдерами для перевірки викликів інструментів + їхнього порядку, читання skill-файлів і wiring сесії. +- Невеликий набір сценаріїв, орієнтованих на skills (використати чи уникнути, gating, prompt injection). +- Опційні live-оцінювання (opt-in, керовані env) лише після появи безпечного для CI набору. -## Контрактні тести (форма plugin і channel) +## Contract-тести (форма Plugin і channel) -Контрактні тести перевіряють, що кожен зареєстрований plugin і channel відповідає -своєму контракту інтерфейсу. Вони проходять по всіх виявлених plugin-ах і запускають набір +Contract-тести перевіряють, що кожен зареєстрований Plugin і channel відповідає своєму +контракту interface. Вони проходять по всіх виявлених plugins і запускають набір перевірок форми та поведінки. Типовий unit lane `pnpm test` навмисно -пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, +пропускає ці файли спільних seams і smoke; запускайте contract-команди явно, коли торкаєтеся спільних поверхонь channel або provider. ### Команди @@ -738,58 +738,58 @@ MCP runtime, виконує інструмент, а потім перевіря Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Базова форма plugin (id, name, capabilities) +- **plugin** - Базова форма Plugin (id, name, capabilities) - **setup** - Контракт майстра налаштування - **session-binding** - Поведінка прив’язки сесії - **outbound-payload** - Структура payload повідомлення - **inbound** - Обробка вхідних повідомлень - **actions** - Обробники дій channel -- **threading** - Обробка thread ID -- **directory** - API каталогу/складу -- **group-policy** - Примусове застосування політики групи +- **threading** - Обробка ID thread +- **directory** - API каталогу/реєстру +- **group-policy** - Застосування політики груп ### Контракти статусу provider Розташовані в `src/plugins/contracts/*.contract.test.ts`. - **status** - Перевірки статусу channel -- **registry** - Форма registry plugin +- **registry** - Форма реєстру Plugin ### Контракти provider Розташовані в `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Контракт потоку auth -- **auth-choice** - Вибір/підбір auth +- **auth** - Контракт потоку автентифікації +- **auth-choice** - Вибір/selection автентифікації - **catalog** - API каталогу моделей -- **discovery** - Виявлення plugin -- **loader** - Завантаження plugin +- **discovery** - Виявлення Plugin +- **loader** - Завантаження Plugin - **runtime** - Runtime провайдера -- **shape** - Форма/інтерфейс plugin +- **shape** - Форма/interface Plugin - **wizard** - Майстер налаштування ### Коли запускати -- Після зміни export-ів або subpath-ів plugin-sdk -- Після додавання або зміни channel чи provider plugin -- Після рефакторингу реєстрації або виявлення plugin +- Після зміни export або subpath у Plugin SDK +- Після додавання або зміни channel чи provider Plugin +- Після рефакторингу реєстрації Plugin або discovery -Контрактні тести запускаються в CI і не потребують реальних API-ключів. +Contract-тести запускаються в CI й не потребують реальних API-ключів. ## Додавання регресій (рекомендації) -Коли ви виправляєте проблему provider/model, виявлену в live: +Коли ви виправляєте проблему провайдера/моделі, виявлену в live: -- Якщо можливо, додайте безпечну для CI регресію (mock/stub provider або захопіть точну трансформацію форми запиту) -- Якщо вона за своєю природою лише live (rate limits, політики auth), зберігайте live-тест вузьким і opt-in через env-змінні -- Віддавайте перевагу націлюванню на найменший шар, який виявляє баг: - - баг конвертації/відтворення запиту провайдера → тест direct models - - баг сесії/history/tool pipeline gateway → gateway live smoke або безпечний для CI gateway mock test +- Додайте безпечну для CI регресію, якщо це можливо (mock/stub provider або фіксація точної трансформації форми запиту) +- Якщо проблема за своєю природою лише live (rate limits, політики auth), залишайте live-тест вузьким і opt-in через env vars +- Віддавайте перевагу найменшому шару, який ловить баг: + - баг перетворення/повторення запиту провайдера → тест прямих моделей + - баг сесії/історії/конвеєра інструментів gateway → Gateway live smoke або безпечний для CI mock-тест gateway - Guardrail обходу SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль на клас SecretRef з метаданих registry (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id сегмента обходу відхиляються. - - Якщо ви додаєте нову сім’ю цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було тихо пропустити. + - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибрану ціль на клас SecretRef з метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id сегмента обходу відхиляються. + - Якщо ви додаєте нове сімейство цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно завершується помилкою для некласифікованих target id, щоб нові класи не можна було тихо пропустити. -## Пов’язані матеріали +## Пов’язане -- [Live-тестування](/uk/help/testing-live) +- [Тестування live](/uk/help/testing-live) - [CI](/uk/ci)