diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index b5cce9f25..f7c277aab 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -1,15 +1,15 @@ --- read_when: - Запуск тестів локально або в CI - - Додавання регресій для багів моделей/провайдерів - - Налагодження поведінки gateway + агента + - Додавання регресій для помилок моделей/провайдерів + - Налагодження поведінки gateway та agent summary: 'Набір тестування: unit/e2e/live набори, Docker-ранери та що покриває кожен тест' title: Тестування x-i18n: - generated_at: "2026-04-06T18:19:41Z" + generated_at: "2026-04-06T18:27:04Z" model: gpt-5.4 provider: openai - source_hash: 1e1e3b5092c91786fb93de1ed84bf3867f6cc85ef797775fa242a56009da3372 + source_hash: bcb6733dba52dd03c625121fc2eb5ef0837553b19698b0c554140f5685fe13b8 source_path: help/testing.md workflow: 15 --- @@ -18,108 +18,108 @@ x-i18n: OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір Docker-ранерів. -Цей документ — посібник «як ми тестуємо»: +Цей документ є посібником «як ми тестуємо»: - Що покриває кожен набір (і що він навмисно _не_ покриває) -- Які команди запускати для типових сценаріїв роботи (локально, перед push, налагодження) +- Які команди запускати для типових сценаріїв (локально, перед push, налагодження) - Як live-тести знаходять облікові дані та вибирають моделі/провайдерів -- Як додавати регресії для реальних проблем моделей/провайдерів +- Як додавати регресії для реальних проблем із моделями/провайдерами ## Швидкий старт У більшості випадків: - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm test` -- Швидший локальний запуск повного набору на потужній машині: `pnpm test:max` +- Швидший локальний запуск повного набору на продуктивній машині: `pnpm test:max` - Прямий цикл спостереження Vitest: `pnpm test:watch` - Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` - QA-сайт на базі Docker: `pnpm qa:lab:up` -Коли ви торкаєтеся тестів або хочете більше впевненості: +Коли ви змінюєте тести або хочете більше впевненості: -- Gate покриття: `pnpm test:coverage` +- Coverage gate: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` -Коли налагоджуєте реальні провайдери/моделі (потрібні реальні облікові дані): +Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): -- Live-набір (моделі + gateway-проби інструментів/зображень): `pnpm test:live` +- Live-набір (моделі + gateway tool/image probes): `pnpm test:live` - Тихо націлитися на один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -Порада: коли вам потрібен лише один збійний випадок, краще звузити live-тести через змінні середовища allowlist, описані нижче. +Порада: якщо вам потрібен лише один збійний випадок, краще звужувати live-тести через змінні середовища allowlist, описані нижче. ## Набори тестів (що де запускається) -Думайте про набори як про «зростання реалізму» (і зростання нестабільності/вартості): +Сприймайте набори як такі, що мають «зростаючий реалізм» (і зростаючу нестабільність/вартість): -### Unit / integration (типово) +### Unit / integration (за замовчуванням) - Команда: `pnpm test` -- Конфіг: п’ять послідовних shard-запусків (`vitest.full-*.config.ts`) поверх наявних scoped-проєктів Vitest -- Файли: core/unit inventory у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і whitelisted `ui` node-тести, охоплені `vitest.unit.config.ts` +- Конфігурація: п’ять послідовних запусків shard (`vitest.full-*.config.ts`) по наявних scoped Vitest projects +- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і дозволені node-тести `ui`, що покриваються `vitest.unit.config.ts` - Обсяг: - Чисті unit-тести - - Внутрішньопроцесні integration-тести (gateway auth, routing, tooling, parsing, config) + - In-process integration-тести (gateway auth, routing, tooling, parsing, config) - Детерміновані регресії для відомих багів - Очікування: - Запускається в CI - Реальні ключі не потрібні - Має бути швидким і стабільним -- Примітка щодо проєктів: - - Ненацілений `pnpm test` тепер запускає п’ять менших shard-конфігів (`core-unit`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського native root-project процесу. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати не пов’язані набори. - - `pnpm test --watch` усе ще використовує граф проєктів native root `vitest.config.ts`, бо multi-shard цикл watch непрактичний. +- Примітка щодо projects: + - Ненацілений `pnpm test` тепер запускає шість менших shard-конфігурацій (`core-unit-src`, `core-unit-support`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського нативного root-project процесу. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати не пов’язані набори. + - `pnpm test --watch` як і раніше використовує граф project із нативного root `vitest.config.ts`, тому що multi-shard watch-цикл непрактичний. - `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. - - Вибрані тести `plugin-sdk` і `commands` також маршрутизуються через окремі легкі lanes, які пропускають `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. - - Вибрані helper source-файли `plugin-sdk` і `commands` також зіставляють changed-mode запуски з явними сусідніми тестами в цих легких lanes, тому зміни helper не примушують повторно запускати весь важкий набір для цього каталогу. - - `auto-reply` тепер має три окремі buckets: top-level core helpers, top-level integration-тести `reply.*` і піддерево `src/auto-reply/reply/**`. Це тримає найважчу роботу reply harness подалі від дешевих статусних/chunk/token тестів. + - `pnpm test:changed` розгортає змінені git-шляхи в ті самі scoped lanes, коли diff торкається лише routable source/test файлів; редагування config/setup як і раніше повертаються до широкого повторного запуску root project. + - Вибрані тести `plugin-sdk` і `commands` також маршрутизуються через виділені легкі lanes, які пропускають `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. + - Вибрані helper source files `plugin-sdk` і `commands` також відображають запуски в режимі changed на явні sibling tests у цих light lanes, щоб редагування helper не перезапускали весь важкий набір для цього каталогу. + - `auto-reply` тепер має три виділені buckets: top-level core helpers, top-level integration-тести `reply.*` і піддерево `src/auto-reply/reply/**`. Це утримує найважчу роботу harness reply подалі від дешевих тестів status/chunk/token. - Примітка щодо embedded runner: - - Коли ви змінюєте входи виявлення message-tool або runtime-контекст compaction, + - Коли ви змінюєте входи виявлення message-tool або контекст runtime compaction, зберігайте обидва рівні покриття. - Додавайте сфокусовані helper-регресії для чистих меж routing/normalization. - - Також підтримуйте здоровими integration-набори embedded runner: + - Також підтримуйте в здоровому стані 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.test.ts` та `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Ці набори перевіряють, що scoped id і поведінка compaction як і раніше проходять + - Ці набори перевіряють, що scoped ids і поведінка compaction усе ще проходять через реальні шляхи `run.ts` / `compact.ts`; лише helper-тести не є достатньою заміною для цих integration-шляхів. - Примітка щодо pool: - - Базовий конфіг Vitest тепер типово використовує `threads`. - - Спільний конфіг Vitest також фіксує `isolate: false` і використовує non-isolated runner у root projects, e2e та live-конфігах. - - Root UI lane зберігає свій `jsdom` setup і optimizer, але тепер також працює на спільному non-isolated runner. - - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` зі спільного конфіга Vitest. - - Спільний launcher `scripts/run-vitest.mjs` тепер також типово додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, якщо потрібно порівняти зі стандартною поведінкою V8. + - Базова конфігурація Vitest тепер за замовчуванням використовує `threads`. + - Спільна конфігурація Vitest також фіксує `isolate: false` і використовує non-isolated runner у root projects, e2e та live configs. + - Root UI lane зберігає свій `jsdom` setup та optimizer, але тепер також працює на спільному non-isolated runner. + - Кожен shard `pnpm test` успадковує ті самі значення за замовчуванням `threads` + `isolate: false` зі спільної конфігурації Vitest. + - Спільний launcher `scripts/run-vitest.mjs` тепер також за замовчуванням додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, якщо хочете порівняти зі стандартною поведінкою V8. - Примітка щодо швидкої локальної ітерації: - - `pnpm test:changed` маршрутизується через scoped lanes, коли змінені шляхи чітко відповідають меншому набору. - - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, лише з вищою межею worker. - - Локальне автоскейлінгування worker тепер навмисно консервативне та також зменшує навантаження, коли середнє навантаження хоста вже високе, тому кілька паралельних запусків Vitest типово менше шкодять системі. - - Базовий конфіг Vitest позначає проєкти/конфіг-файли як `forceRerunTriggers`, щоб повторні запуски в changed-mode залишалися коректними, коли змінюється wiring тестів. - - Конфіг зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних хостах; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання. -- Примітка щодо налагодження продуктивності: - - `pnpm test:perf:imports` вмикає звітність про тривалість імпорту Vitest та вивід розбивки імпортів. - - `pnpm test:perf:imports:changed` обмежує той самий профільований вигляд файлами, зміненими відносно `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований `test:changed` із шляхом native root-project для цього закоміченого diff і виводить wall time плюс macOS max RSS. -- `pnpm test:perf:changed:bench -- --worktree` вимірює поточне брудне дерево, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і root-конфіг Vitest. - - `pnpm test:perf:profile:main` записує CPU-профіль main-thread для накладних витрат запуску й трансформації Vitest/Vite. - - `pnpm test:perf:profile:runner` записує CPU+heap профілі runner для unit-набору з вимкненим файловим паралелізмом. + - `pnpm test:changed` маршрутизує через scoped lanes, коли змінені шляхи однозначно відповідають меншому набору. + - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, лише з вищою межею workers. + - Автомасштабування локальних workers тепер навмисно консервативніше та також зменшується, коли середнє навантаження хоста вже високе, тож кілька одночасних запусків Vitest за замовчуванням завдають менше шкоди. + - Базова конфігурація Vitest позначає projects/config files як `forceRerunTriggers`, щоб повторні запуски в режимі changed залишалися коректними при зміні wiring тестів. + - Конфігурація залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних хостах; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання. +- Примітка щодо perf-debug: + - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість import, а також вивід розбивки import. + - `pnpm test:perf:imports:changed` обмежує той самий вид профілювання файлами, зміненими відносно `origin/main`. +- `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований `test:changed` із нативним шляхом root-project для цього зафіксованого diff і виводить wall time та macOS max RSS. +- `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного dirty tree, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і root Vitest config. + - `pnpm test:perf:profile:main` записує main-thread CPU profile для накладних витрат запуску й transform у Vitest/Vite. + - `pnpm test:perf:profile:runner` записує runner CPU+heap profiles для unit-набору з вимкненим file parallelism. ### E2E (gateway smoke) - Команда: `pnpm test:e2e` -- Конфіг: `vitest.e2e.config.ts` +- Конфігурація: `vitest.e2e.config.ts` - Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` -- Типові параметри runtime: +- Значення runtime за замовчуванням: - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. - - Використовує адаптивні workers (CI: до 2, локально: 1 типово). - - Типово працює в silent mode, щоб зменшити накладні витрати console I/O. + - Використовує adaptive workers (CI: до 2, локально: 1 за замовчуванням). + - За замовчуванням запускається в silent mode, щоб зменшити накладні витрати на console I/O. - Корисні перевизначення: - - `OPENCLAW_E2E_WORKERS=` щоб примусово задати кількість worker (обмежено 16). - - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний вивід у консоль. + - `OPENCLAW_E2E_WORKERS=` щоб примусово задати кількість workers (обмежено 16). + - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути детальний console output. - Обсяг: - - Наскрізна поведінка multi-instance gateway - - Поверхні WebSocket/HTTP, pairing вузлів і важче мережеве навантаження + - End-to-end поведінка multi-instance gateway + - Поверхні WebSocket/HTTP, pairings вузлів і важча мережева взаємодія - Очікування: - - Запускається в CI (коли ввімкнено в pipeline) + - Запускається в CI (коли увімкнено в pipeline) - Реальні ключі не потрібні - Більше рухомих частин, ніж у unit-тестах (може бути повільніше) @@ -130,130 +130,130 @@ OpenClaw має три набори Vitest (unit/integration, e2e, live) і не - Обсяг: - Запускає ізольований OpenShell gateway на хості через Docker - Створює sandbox із тимчасового локального Dockerfile - - Проганяє OpenShell backend у OpenClaw через реальні `sandbox ssh-config` + SSH exec + - Перевіряє OpenShell backend в OpenClaw через реальні `sandbox ssh-config` + SSH exec - Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge - Очікування: - - Лише opt-in; не є частиною типового запуску `pnpm test:e2e` - - Потребує локальний CLI `openshell` і робочий Docker daemon - - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, після чого знищує test gateway і sandbox + - Лише opt-in; не входить до стандартного запуску `pnpm test:e2e` + - Потрібен локальний CLI `openshell` і робочий Docker daemon + - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує test gateway і sandbox - Корисні перевизначення: - `OPENCLAW_E2E_OPENSHELL=1` щоб увімкнути тест під час ручного запуску ширшого e2e-набору - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб вказати нестандартний бінарний файл CLI або wrapper script + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб вказати нестандартний CLI binary або wrapper script ### Live (реальні провайдери + реальні моделі) - Команда: `pnpm test:live` -- Конфіг: `vitest.live.config.ts` +- Конфігурація: `vitest.live.config.ts` - Файли: `src/**/*.live.test.ts` -- Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) +- За замовчуванням: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) - Обсяг: - «Чи справді цей провайдер/модель працює _сьогодні_ з реальними обліковими даними?» - - Виявлення змін формату провайдера, особливостей виклику інструментів, проблем auth і поведінки rate limit + - Виявлення змін форматів провайдерів, особливостей tool-calling, проблем auth і поведінки rate limit - Очікування: - - Навмисно не є CI-стабільним (реальні мережі, реальні політики провайдерів, квоти, збої) - - Коштує грошей / використовує rate limits - - Краще запускати звужені підмножини замість «усього» -- 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`, якщо хочете повернути повні startup-логи. -- Ротація API-ключів (залежно від провайдера): установіть `*_API_KEYS` у форматі comma/semicolon або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або використайте перевизначення для конкретного live-запуску через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу у відповідь на rate limit. + - За задумом не є CI-stable (реальні мережі, реальні політики провайдерів, квоти, збої) + - Коштує грошей / витрачає rate limits + - Краще запускати звужені підмножини, а не «все» +- Live-запуски підвантажують `~/.profile`, щоб підхопити відсутні API keys. +- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють config/auth material у тимчасовий 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 keys (залежно від провайдера): задавайте `*_API_KEYS` у форматі comma/semicolon або `*_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` вимикає interception консолі Vitest, щоб рядки прогресу провайдера/gateway одразу транслювалися під час live-запусків. - - Налаштовуйте heartbeat для direct-model через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштовуйте heartbeat для gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - Live-набори тепер надсилають рядки прогресу до stderr, щоб було видно, що довгі виклики провайдерів активні, навіть коли console capture Vitest тихий. + - `vitest.live.config.ts` вимикає console interception у Vitest, щоб рядки прогресу провайдера/gateway передавалися одразу під час live-запусків. + - Налаштовуйте heartbeats прямих моделей через `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Налаштовуйте heartbeats gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Який набір мені запускати? +## Який набір запускати? Використовуйте цю таблицю рішень: -- Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) -- Торкаєтеся мережевої логіки gateway / WS protocol / pairing: додайте `pnpm test:e2e` -- Налагоджуєте «мій бот не працює» / збої конкретного провайдера / виклик інструментів: запускайте звужений `pnpm test:live` +- Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо багато змінили) +- Торкаєтеся мережевої взаємодії gateway / протоколу WS / pairing: додайте `pnpm test:e2e` +- Налагоджуєте «мій бот не працює» / збої, специфічні для провайдера / tool calling: запускайте звужений `pnpm test:live` -## Live: перевірка можливостей Android node +## Live: огляд можливостей Android node - Тест: `src/gateway/android-node.capabilities.live.test.ts` - Скрипт: `pnpm android:test:integration` -- Мета: викликати **кожну команду, яка зараз оголошена** підключеним Android-вузлом, і перевірити поведінку контракту команди. +- Мета: викликати **кожну команду, що зараз оголошена** підключеним Android node, і перевірити поведінку command contract. - Обсяг: - - Попередньо підготовлене/ручне налаштування (набір не встановлює/не запускає/не pair-ить застосунок). - - Перевірка gateway `node.invoke` для вибраного Android node, команда за командою. -- Обов’язкове попереднє налаштування: - - Android-застосунок уже підключений і pair-ений із gateway. - - Застосунок утримується на передньому плані. - - Дозволи/згода на захоплення надані для можливостей, проходження яких ви очікуєте. + - Попередньо підготовлене/ручне налаштування (набір не встановлює, не запускає й не pair-ить app). + - Валідація gateway `node.invoke` по командах для вибраного Android node. +- Необхідна попередня підготовка: + - Android app уже підключено й pair-ено до gateway. + - App утримується на передньому плані. + - Надано permissions/consent на capture для можливостей, які ви очікуєте пройти. - Необов’язкові перевизначення цілі: - `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) -## Live: smoke моделей (ключі профілю) +## Live: smoke моделей (profile keys) -Live-тести розділені на два рівні, щоб можна було ізолювати збої: +Live-тести поділено на два шари, щоб можна було ізолювати збої: -- «Direct model» показує, чи може провайдер/модель взагалі відповісти з наданим ключем. +- «Direct model» показує, чи може провайдер/модель взагалі відповісти з указаним ключем. - «Gateway smoke» показує, чи працює повний pipeline gateway+agent для цієї моделі (sessions, history, tools, sandbox policy тощо). -### Рівень 1: Direct model completion (без gateway) +### Шар 1: Пряме завершення моделі (без gateway) - Тест: `src/agents/models.profiles.live.test.ts` - Мета: - Перелічити виявлені моделі - Використати `getApiKeyForModel` для вибору моделей, для яких у вас є облікові дані - - Виконати невелике completion для кожної моделі (і цільові регресії, де потрібно) + - Виконати невелике completion для кожної моделі (і цільові регресії там, де потрібно) - Як увімкнути: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму) -- Установіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб реально запустити цей набір; інакше він пропускається, щоб `pnpm test:live` залишався зосередженим на gateway smoke -- Як вибрати моделі: - - `OPENCLAW_LIVE_MODELS=modern` щоб запустити modern allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) +- Встановіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб цей набір справді запускався; інакше його буде пропущено, щоб `pnpm test:live` лишався зосередженим на gateway smoke +- Як вибирати моделі: + - `OPENCLAW_LIVE_MODELS=modern`, щоб запустити modern allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `OPENCLAW_LIVE_MODELS=all` — це псевдонім для modern allowlist - або `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (comma allowlist) -- Як вибрати провайдерів: +- Як вибирати провайдерів: - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (comma allowlist) - Звідки беруться ключі: - - Типово: profile store і env fallback - - Установіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати **лише profile store** + - За замовчуванням: profile store і резервні env + - Встановіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати **лише profile store** - Навіщо це існує: - Відокремлює «API провайдера зламане / ключ недійсний» від «pipeline gateway agent зламаний» - - Містить невеликі ізольовані регресії (приклад: OpenAI Responses/Codex Responses reasoning replay + потоки tool-call) + - Містить невеликі ізольовані регресії (наприклад: OpenAI Responses/Codex Responses reasoning replay + потоки tool-call) -### Рівень 2: Gateway + smoke dev agent (що реально робить "@openclaw") +### Шар 2: smoke gateway + dev agent (що насправді робить "@openclaw") - Тест: `src/gateway/gateway-models.profiles.live.test.ts` - Мета: - Підняти in-process gateway - - Створити/оновити session `agent:dev:*` (перевизначення моделі для кожного запуску) - - Ітеруватися по моделях із ключами та перевіряти: - - «змістовну» відповідь (без інструментів) - - що працює реальний виклик інструмента (read probe) - - необов’язкові додаткові проби інструментів (exec+read probe) - - що шляхи регресії OpenAI (лише tool-call → follow-up) продовжують працювати -- Деталі проб (щоб ви могли швидко пояснювати збої): - - `read` probe: тест записує файл nonce у workspace і просить агента `read` його та повернути nonce у відповіді. - - `exec+read` probe: тест просить агента записати nonce у тимчасовий файл через `exec`, а потім прочитати його через `read`. + - Створити/оновити сесію `agent:dev:*` (перевизначення моделі на запуск) + - Перебрати models-with-keys і перевірити: + - «змістовну» відповідь (без tools) + - що працює реальний виклик tool (read probe) + - необов’язкові додаткові tool probes (exec+read probe) + - що шляхи регресії OpenAI (лише tool-call → follow-up) залишаються працездатними +- Деталі probe (щоб ви могли швидко пояснювати збої): + - `read` probe: тест записує nonce-файл у workspace й просить agent `read` його та повернути nonce. + - `exec+read` probe: тест просить agent записати nonce у тимчасовий файл через `exec`, а потім прочитати його через `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.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) +- Як вибирати моделі: + - За замовчуванням: modern allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) - `OPENCLAW_LIVE_GATEWAY_MODELS=all` — це псевдонім для modern allowlist - Або встановіть `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (або comma list), щоб звузити -- Як вибрати провайдерів (уникати «весь OpenRouter»): +- Як вибирати провайдерів (уникайте «OpenRouter everything»): - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (comma allowlist) -- Проби інструментів і зображень у цьому live-тесті завжди ввімкнені: - - `read` probe + `exec+read` probe (навантаження на інструменти) - - image probe запускається, коли модель декларує підтримку вводу зображень +- Tool + image probes завжди увімкнені в цьому live-тесті: + - `read` probe + `exec+read` probe (tool stress) + - image probe запускається, коли модель оголошує підтримку image input - Потік (високорівнево): - - Тест генерує маленький 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`) - - Embedded agent пересилає multimodal user message у модель - - Перевірка: відповідь містить `cat` + код (допуск OCR: незначні помилки дозволені) + - Gateway розбирає attachments у `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) + - Embedded agent передає мультимодальне повідомлення користувача моделі + - Перевірка: відповідь містить `cat` + код (OCR tolerance: дрібні помилки допустимі) -Порада: щоб побачити, що саме можна тестувати на вашій машині (і точні ідентифікатори `provider/model`), запустіть: +Порада: щоб побачити, що саме можна тестувати на вашій машині (і точні ідентифікатори `provider/model`), виконайте: ```bash openclaw models list @@ -263,23 +263,23 @@ openclaw models list --json ## Live: smoke CLI backend (Codex CLI або інші локальні CLI) - Тест: `src/gateway/gateway-cli-backend.live.test.ts` -- Мета: перевірити pipeline Gateway + agent за допомогою локального CLI backend, не торкаючись вашого типового config. +- Мета: перевірити pipeline Gateway + agent за допомогою локального CLI backend, не торкаючись вашого стандартного config. - Увімкнення: - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму) - `OPENCLAW_LIVE_CLI_BACKEND=1` -- Типові значення: +- Значення за замовчуванням: - Модель: `codex-cli/gpt-5.4` - Команда: `codex` - - Аргументи: `["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]` + - Args: `["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]` - Перевизначення (необов’язково): - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"` - `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). - - `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` щоб надіслати другий хід і перевірити flow відновлення. - + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` щоб надіслати реальне вкладення image (шляхи впроваджуються в prompt). + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` щоб передавати шляхи до image-файлів як CLI args замість впровадження в prompt. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`), щоб керувати способом передавання image args, коли задано `IMAGE_ARG`. + - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` щоб надіслати другий хід і перевірити flow resume. + Приклад: ```bash @@ -288,7 +288,7 @@ OPENCLAW_LIVE_CLI_BACKEND=1 \ pnpm test:live src/gateway/gateway-cli-backend.live.test.ts ``` -Docker-рецепт: +Рецепт Docker: ```bash pnpm test:docker:live-cli-backend @@ -296,32 +296,32 @@ pnpm test:docker:live-cli-backend Примітки: -- Docker-ранер розташований у `scripts/test-live-cli-backend-docker.sh`. -- Він запускає live smoke CLI-backend усередині Docker-образу репозиторію від непривілейованого користувача `node`. -- Для `codex-cli` він встановлює Linux-пакет `@openai/codex` у кешований записуваний префікс за адресою `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (типово: `~/.cache/openclaw/docker-cli-tools`). +- Docker-ранер знаходиться в `scripts/test-live-cli-backend-docker.sh`. +- Він запускає live smoke CLI-backend усередині Docker-образу репозиторію як non-root користувач `node`. +- Для `codex-cli` він встановлює Linux-пакет `@openai/codex` у кешований записуваний префікс за адресою `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`). ## Live: smoke ACP bind (`/acp spawn ... --bind here`) - Тест: `src/gateway/gateway-acp-bind.live.test.ts` -- Мета: перевірити реальний flow conversation-bind ACP із live ACP agent: +- Мета: перевірити реальний flow bind розмови ACP з live ACP agent: - надіслати `/acp spawn --bind here` - - прив’язати synthetic conversation каналу повідомлень на місці - - надіслати звичайне follow-up повідомлення в тій самій conversation - - перевірити, що follow-up потрапляє в transcript прив’язаної ACP session + - прив’язати синтетичну розмову message-channel на місці + - надіслати звичайне follow-up у цій самій розмові + - перевірити, що follow-up потрапляє до transcript прив’язаної ACP session - Увімкнення: - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` -- Типові значення: +- Значення за замовчуванням: - ACP agent: `claude` - - Synthetic channel: контекст conversation у стилі Slack DM + - Синтетичний channel: контекст розмови в стилі Slack DM - ACP backend: `acpx` - Перевизначення: - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude` - `OPENCLAW_LIVE_ACP_BIND_AGENT=codex` - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` - Примітки: - - Ця lane використовує поверхню gateway `chat.send` з admin-only synthetic originating-route полями, щоб тести могли прикріплювати контекст message-channel, не вдаючи зовнішню доставку. - - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не задано, тест використовує вбудований реєстр агентів плагіна `acpx` для вибраного ACP harness agent. + - Ця lane використовує поверхню gateway `chat.send` з admin-only синтетичними полями originating-route, щоб тести могли додавати контекст message-channel без імітації зовнішньої доставки. + - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не встановлено, тест використовує вбудований реєстр agent плагіна `acpx` для вибраного ACP harness agent. Приклад: @@ -331,7 +331,7 @@ 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 @@ -339,13 +339,13 @@ pnpm test:docker:live-acp-bind Примітки щодо Docker: -- Docker-ранер розташований у `scripts/test-live-acp-bind-docker.sh`. -- Він використовує `~/.profile`, переносить відповідний CLI auth material у контейнер, встановлює `acpx` у записуваний npm-префікс, а потім встановлює запитаний live CLI (`@anthropic-ai/claude-code` або `@openai/codex`), якщо його бракує. -- Усередині Docker раннер встановлює `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, щоб acpx зберігав env vars провайдера з використаного profile доступними для дочірнього harness CLI. +- Docker-ранер знаходиться в `scripts/test-live-acp-bind-docker.sh`. +- Він підвантажує `~/.profile`, переносить відповідний CLI auth material у контейнер, встановлює `acpx` у записуваний npm prefix, а потім за потреби встановлює потрібний live CLI (`@anthropic-ai/claude-code` або `@openai/codex`). +- Усередині Docker раннер встановлює `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, щоб `acpx` зберігав env vars провайдера із підвантаженого profile доступними для дочірнього harness CLI. ### Рекомендовані live-рецепти -Вузькі явні allowlist працюють найшвидше і найменш нестабільно: +Вузькі явні allowlists — найшвидші й найменш нестабільні: - Одна модель, direct (без gateway): - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts` @@ -353,29 +353,29 @@ pnpm test:docker:live-acp-bind - Одна модель, gateway smoke: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Виклик інструментів через кількох провайдерів: +- Tool calling у кількох провайдерів: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Фокус на Google (API-ключ Gemini + Antigravity): +- Фокус на Google (Gemini API key + Antigravity): - Gemini (API key): `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` Примітки: - `google/...` використовує Gemini API (API key). -- `google-antigravity/...` використовує міст OAuth Antigravity (ендпоінт агента у стилі Cloud Code Assist). -- `google-gemini-cli/...` використовує локальний Gemini CLI на вашій машині (окрема auth + особливості інструментів). +- `google-antigravity/...` використовує міст Antigravity OAuth (agent endpoint у стилі Cloud Code Assist). +- `google-gemini-cli/...` використовує локальний Gemini CLI на вашій машині (окрема auth + особливості tooling). - Gemini API проти Gemini CLI: - - API: OpenClaw викликає хостований Gemini API від Google через HTTP (API key / profile auth); це те, що більшість користувачів мають на увазі під «Gemini». - - CLI: OpenClaw виконує локальний бінарний файл `gemini`; він має власну auth і може поводитися інакше (streaming/підтримка інструментів/version skew). + - API: OpenClaw викликає хостований Gemini API від Google через HTTP (API key / profile auth); саме це більшість користувачів мають на увазі під «Gemini». + - CLI: OpenClaw виконує shell-out до локального binary `gemini`; він має власну auth і може поводитися інакше (streaming/tool support/version skew). ## Live: матриця моделей (що ми покриваємо) -Немає фіксованого «списку моделей CI» (live є opt-in), але ось **рекомендовані** моделі, які варто регулярно покривати на dev-машині з ключами. +Фіксованого «списку моделей CI» немає (live — opt-in), але ось **рекомендовані** моделі, які варто регулярно покривати на машині розробника з ключами. -### Сучасний smoke-набір (виклик інструментів + зображення) +### Сучасний smoke-набір (tool calling + image) -Це запуск «поширених моделей», який ми очікуємо підтримувати в робочому стані: +Це запуск «поширених моделей», який ми очікуємо зберігати працездатним: - OpenAI (не-Codex): `openai/gpt-5.4` (необов’язково: `openai/gpt-5.4-mini`) - OpenAI Codex: `openai-codex/gpt-5.4` @@ -385,10 +385,10 @@ pnpm test:docker:live-acp-bind - Z.AI (GLM): `zai/glm-4.7` - MiniMax: `minimax/MiniMax-M2.7` -Запустити gateway smoke з інструментами + зображенням: +Запуск gateway smoke з tools + image: `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,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,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -### Базовий рівень: виклик інструментів (Read + необов’язковий Exec) +### Базовий рівень: tool calling (Read + необов’язковий Exec) Виберіть щонайменше одну модель на сімейство провайдерів: @@ -400,79 +400,79 @@ pnpm test:docker:live-acp-bind Необов’язкове додаткове покриття (було б добре мати): -- xAI: `xai/grok-4` (або найновіша доступна) -- Mistral: `mistral/`… (виберіть одну модель із підтримкою `tools`, яку у вас ввімкнено) +- xAI: `xai/grok-4` (або найновішу доступну) +- Mistral: `mistral/`… (виберіть одну модель із підтримкою `tools`, яку у вас увімкнено) - Cerebras: `cerebras/`… (якщо у вас є доступ) -- LM Studio: `lmstudio/`… (локально; виклик інструментів залежить від режиму API) +- LM Studio: `lmstudio/`… (локально; tool calling залежить від режиму API) -### Vision: надсилання зображень (вкладення → multimodal message) +### Vision: надсилання image (вкладення → мультимодальне повідомлення) -Додайте щонайменше одну модель із підтримкою зображень у `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/OpenAI vision-capable варіанти тощо), щоб перевірити image probe. +Додайте щонайменше одну модель із підтримкою image до `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/OpenAI vision-capable variants тощо), щоб перевірити image probe. ### Агрегатори / альтернативні gateway Якщо у вас увімкнені ключі, ми також підтримуємо тестування через: -- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти кандидатів із підтримкою tools+image) +- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти кандидатів із підтримкою tool+image) - OpenCode: `opencode/...` для Zen і `opencode-go/...` для Go (auth через `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) Більше провайдерів, які можна включити до live-матриці (якщо у вас є облікові дані/config): - Вбудовані: `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` (власні endpoints): `minimax` (cloud/API), плюс будь-який сумісний із OpenAI/Anthropic proxy (LM Studio, vLLM, LiteLLM тощо) +- Через `models.providers` (кастомні endpoints): `minimax` (cloud/API), а також будь-який OpenAI/Anthropic-compatible proxy (LM Studio, vLLM, LiteLLM тощо) -Порада: не намагайтеся жорстко закодувати «всі моделі» в документації. Авторитетним списком є те, що повертає `discoverModels(...)` на вашій машині, плюс доступні ключі. +Порада: не намагайтеся жорстко закодувати «всі моделі» в документації. Авторитетний список — це те, що повертає `discoverModels(...)` на вашій машині, плюс ті ключі, які доступні. -## Облікові дані (ніколи не комітьте) +## Облікові дані (ніколи не commit) Live-тести знаходять облікові дані так само, як це робить CLI. Практичні наслідки: -- Якщо CLI працює, live-тести мають знаходити ті самі ключі. -- Якщо live-тест повідомляє «немає облікових даних», налагоджуйте це так само, як налагоджували б `openclaw models list` / вибір моделі. +- Якщо CLI працює, live-тести мають знайти ті самі ключі. +- Якщо live-тест каже «немає облікових даних», налагоджуйте це так само, як налагоджували б `openclaw models list` / вибір моделі. -- Auth-профілі на рівні агента: `~/.openclaw/agents//agent/auth-profiles.json` (це і є те, що в live-тестах означає «profile keys») +- Per-agent auth profiles: `~/.openclaw/agents//agent/auth-profiles.json` (це і є значення «profile keys» у live-тестах) - Config: `~/.openclaw/openclaw.json` (або `OPENCLAW_CONFIG_PATH`) -- Каталог legacy state: `~/.openclaw/credentials/` (копіюється в staged live home, якщо присутній, але це не основне сховище profile-key) -- Локальні live-запуски типово копіюють активний config, файли `auth-profiles.json` для кожного агента, legacy `credentials/` і підтримувані зовнішні каталоги auth CLI у тимчасовий test home; перевизначення шляхів `agents.*.workspace` / `agentDir` видаляються з цього staged config, щоб probes не торкалися вашого реального host workspace. +- Застарілий каталог стану: `~/.openclaw/credentials/` (копіюється у staged live home, коли присутній, але це не основне сховище profile-key) +- Локальні live-запуски за замовчуванням копіюють активний config, per-agent файли `auth-profiles.json`, застарілий каталог `credentials/` і підтримувані зовнішні каталоги CLI auth у тимчасовий test home; перевизначення шляхів `agents.*.workspace` / `agentDir` видаляються в цьому staged config, щоб probes не торкалися вашого реального workspace хоста. -Якщо ви хочете покладатися на env keys (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile`, або використовуйте Docker-ранери нижче (вони можуть монтувати `~/.profile` у контейнер). +Якщо ви хочете покладатися на env keys (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile`, або використовуйте Docker-ранери нижче (вони можуть змонтувати `~/.profile` у контейнер). -## Deepgram live (транскрипція аудіо) +## Live Deepgram (транскрипція аудіо) - Тест: `src/media-understanding/providers/deepgram/audio.live.test.ts` - Увімкнення: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts` -## BytePlus coding plan live +## Live BytePlus coding plan - Тест: `src/agents/byteplus.live.test.ts` - Увімкнення: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts` - Необов’язкове перевизначення моделі: `BYTEPLUS_CODING_MODEL=ark-code-latest` -## ComfyUI workflow media live +## Live медіа workflow ComfyUI - Тест: `extensions/comfy/comfy.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` - Обсяг: - - Проганяє вбудовані шляхи comfy image, video та `music_generate` - - Пропускає кожну можливість, якщо `models.providers.comfy.` не налаштовано - - Корисно після змін у відправленні comfy workflow, polling, downloads або реєстрації plugin + - Перевіряє вбудовані шляхи comfy для image, video і `music_generate` + - Пропускає кожну можливість, якщо не налаштовано `models.providers.comfy.` + - Корисно після змін у поданні workflow comfy, polling, downloads або реєстрації plugin -## Live генерації зображень +## Live генерація image - Тест: `src/image-generation/runtime.live.test.ts` - Команда: `pnpm test:live src/image-generation/runtime.live.test.ts` - Harness: `pnpm test:live:media image` - Обсяг: - - Перелічує кожен зареєстрований provider plugin генерації зображень - - Завантажує відсутні provider env vars з вашого login shell (`~/.profile`) перед probing - - Типово використовує live/env API keys раніше за збережені auth profiles, щоб застарілі test keys у `auth-profiles.json` не маскували реальні shell credentials - - Пропускає провайдерів без придатних auth/profile/model - - Запускає стандартні варіанти генерації зображень через спільну runtime capability: + - Перелічує кожен зареєстрований provider plugin генерації image + - Завантажує відсутні env vars провайдера з вашого shell входу (`~/.profile`) перед перевіркою + - За замовчуванням використовує live/env API keys раніше за збережені auth profiles, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні shell credentials + - Пропускає провайдерів без придатної auth/profile/model + - Запускає стандартні варіанти генерації image через спільну можливість runtime: - `google:flash-generate` - `google:pro-generate` - `google:pro-edit` - `openai:default-generate` -- Поточні вбудовані провайдери в покритті: +- Поточні вбудовані провайдери, що покриваються: - `openai` - `google` - Необов’язкове звуження: @@ -480,68 +480,68 @@ Live-тести знаходять облікові дані так само, я - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-1,google/gemini-3.1-flash-image-preview"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit"` - Необов’язкова поведінка auth: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth із profile store та ігнорувати перевизначення лише через env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth із profile-store та ігнорувати env-only перевизначення -## Live генерації музики +## Live генерація музики - Тест: `extensions/music-generation-providers.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Harness: `pnpm test:live:media music` - Обсяг: - - Проганяє спільний шлях bundled provider генерації музики - - Наразі охоплює Google і MiniMax - - Завантажує provider env vars з вашого login shell (`~/.profile`) перед probing - - Типово використовує live/env API keys раніше за збережені auth profiles, щоб застарілі test keys у `auth-profiles.json` не маскували реальні shell credentials - - Пропускає провайдерів без придатних auth/profile/model - - Запускає обидва оголошені runtime-режими, коли вони доступні: - - `generate` з input лише на основі prompt + - Перевіряє спільний вбудований шлях provider генерації музики + - Наразі покриває Google і MiniMax + - Завантажує env vars провайдера з вашого shell входу (`~/.profile`) перед перевіркою + - За замовчуванням використовує live/env API keys раніше за збережені auth profiles, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні shell credentials + - Пропускає провайдерів без придатної auth/profile/model + - Запускає обидва оголошені режими runtime, коли вони доступні: + - `generate` із вхідними даними лише у вигляді prompt - `edit`, коли провайдер оголошує `capabilities.edit.enabled` - Поточне покриття спільної lane: - `google`: `generate`, `edit` - `minimax`: `generate` - - `comfy`: окремий live-файл Comfy, а не цей спільний обхід + - `comfy`: окремий live-файл Comfy, не цей спільний sweep - Необов’язкове звуження: - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"` - Необов’язкова поведінка auth: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth із profile store та ігнорувати перевизначення лише через env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth із profile-store та ігнорувати env-only перевизначення -## Live генерації відео +## Live генерація відео - Тест: `extensions/video-generation-providers.live.test.ts` - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harness: `pnpm test:live:media video` - Обсяг: - - Проганяє спільний шлях bundled provider генерації відео - - Завантажує provider env vars з вашого login shell (`~/.profile`) перед probing - - Типово використовує live/env API keys раніше за збережені auth profiles, щоб застарілі test keys у `auth-profiles.json` не маскували реальні shell credentials - - Пропускає провайдерів без придатних auth/profile/model - - Запускає обидва оголошені runtime-режими, коли вони доступні: - - `generate` з input лише на основі prompt - - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled` і вибраний provider/model приймає buffer-backed локальний ввід зображення у спільному обході - - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled` і вибраний provider/model приймає buffer-backed локальний ввід відео у спільному обході - - Поточні `imageToVideo` провайдери, оголошені, але пропущені у спільному обході: - - `vydra`, тому що вбудований `veo3` є лише текстовим, а вбудований `kling` вимагає віддалений URL зображення + - Перевіряє спільний вбудований шлях provider генерації відео + - Завантажує env vars провайдера з вашого shell входу (`~/.profile`) перед перевіркою + - За замовчуванням використовує live/env API keys раніше за збережені auth profiles, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні shell credentials + - Пропускає провайдерів без придатної auth/profile/model + - Запускає обидва оголошені режими runtime, коли вони доступні: + - `generate` із вхідними даними лише у вигляді prompt + - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled` і вибраний provider/model приймає локальний image input із буфера в спільному sweep + - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled` і вибраний provider/model приймає локальний video input із буфера в спільному sweep + - Поточні оголошені, але пропущені провайдери `imageToVideo` у спільному sweep: + - `vydra`, тому що вбудований `veo3` підтримує лише текст, а вбудований `kling` вимагає віддалену image URL - Поточне live-покриття `videoToVideo`: - - лише `runway`, коли вибрана модель — `runway/gen4_aleph` - - Поточні `videoToVideo` провайдери, оголошені, але пропущені у спільному обході: - - `alibaba`, `qwen`, `xai`, тому що ці шляхи наразі потребують віддалених reference URL `http(s)` / MP4 - - `google`, тому що поточна спільна lane Gemini/Veo використовує локальний buffer-backed input, і цей шлях не приймається у спільному обході - - `openai`, тому що поточна спільна lane не гарантує org-specific доступ до video inpaint/remix + - лише `runway`, коли вибраною моделлю є `runway/gen4_aleph` + - Поточні оголошені, але пропущені провайдери `videoToVideo` у спільному sweep: + - `alibaba`, `qwen`, `xai`, оскільки ці шляхи наразі вимагають віддалених reference URL `http(s)` / MP4 + - `google`, оскільки поточна спільна lane Gemini/Veo використовує локальний buffer-backed input, і цей шлях не приймається в спільному sweep + - `openai`, оскільки поточна спільна lane не гарантує наявність доступу до org-specific video inpaint/remix - Необов’язкове звуження: - `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"` - Необов’язкова поведінка auth: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth із profile store та ігнорувати перевизначення лише через env + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth із profile-store та ігнорувати env-only перевизначення -## Media live harness +## Harness live-медіа - Команда: `pnpm test:live:media` - Призначення: - - Запускає спільні live-набори image, music і video через один рідний для репозиторію entrypoint - - Автоматично завантажує відсутні provider env vars із `~/.profile` - - Типово автоматично звужує кожен набір до провайдерів, які зараз мають придатну auth - - Повторно використовує `scripts/test-live.mjs`, тож поведінка heartbeat і quiet-mode залишається узгодженою + - Запускає спільні live-набори image, music і video через один нативний entrypoint репозиторію + - Автоматично завантажує відсутні env vars провайдера з `~/.profile` + - За замовчуванням автоматично звужує кожен набір до провайдерів, які наразі мають придатну auth + - Повторно використовує `scripts/test-live.mjs`, тож поведінка heartbeat і quiet mode залишається узгодженою - Приклади: - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` @@ -550,123 +550,123 @@ Live-тести знаходять облікові дані так само, я ## Docker-ранери (необов’язкові перевірки «працює в Linux») -Ці Docker-ранери поділяються на дві категорії: +Ці Docker-ранери поділяються на дві групи: -- Live-model ранери: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл profile-key усередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтуючи ваш локальний config dir і workspace (і використовуючи `~/.profile`, якщо він змонтований). Відповідні локальні entrypoint — `test:live:models-profiles` і `test:live:gateway-profiles`. -- Docker live-ранери типово використовують меншу smoke-стелю, щоб повний Docker-обхід залишався практичним: - `test:docker:live-models` типово встановлює `OPENCLAW_LIVE_MAX_MODELS=12`, а - `test:docker:live-gateway` типово встановлює `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, +- Live-model ранери: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл для profile-key усередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтуючи ваш локальний config dir і workspace (та підвантажуючи `~/.profile`, якщо змонтовано). Відповідні локальні entrypoints: `test:live:models-profiles` і `test:live:gateway-profiles`. +- Docker live-ранери за замовчуванням використовують меншу межу smoke, щоб повний Docker sweep залишався практичним: + `test:docker:live-models` за замовчуванням встановлює `OPENCLAW_LIVE_MAX_MODELS=12`, а + `test:docker:live-gateway` за замовчуванням встановлює `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` і `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли - вам навмисно потрібен більший вичерпний обхід. -- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, а потім повторно використовує його для двох Docker live-lane. -- Container smoke-ранери: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` і `test:docker:plugins` піднімають один або кілька реальних контейнерів і перевіряють integration-шляхи вищого рівня. + свідомо хочете більший вичерпний scan. +- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, а потім повторно використовує його для двох live Docker lanes. +- Container smoke-ранери: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` і `test:docker:plugins` запускають один або більше реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. -Live-model Docker-ранери також bind-mount лише потрібні CLI auth homes (або всі підтримувані, коли запуск не звужений), а потім копіюють їх у container home перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени, не змінюючи host auth store: +Live-model Docker-ранери також bind-mount лише потрібні CLI auth homes (або всі підтримувані, якщо запуск не звужено), а потім копіюють їх у home контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без зміни host auth store: -- Direct models: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) +- Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) - ACP bind smoke: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`) - CLI backend smoke: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) - Gateway + dev agent: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-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`) -- Мережа gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) -- Міст MCP channel (seeded Gateway + stdio bridge + raw Claude notification-frame smoke): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) +- Open WebUI live smoke: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Майстер onboarding (TTY, повне scaffold-налаштування): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) +- Мережева взаємодія gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) +- MCP channel bridge (seeded Gateway + stdio bridge + raw Claude notification-frame smoke): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) - Plugins (install smoke + псевдонім `/plugin` + семантика restart Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) -Live-model Docker-ранери також bind-mount-ять поточний checkout лише для читання і -переносять його у тимчасовий workdir усередині контейнера. Це тримає runtime -image компактним, але все одно запускає Vitest точно на вашому локальному source/config. -Крок staging пропускає великі локальні кеші та виходи збірки застосунків, такі як -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні каталоги `.build` або -Gradle output, щоб Docker live-запуски не витрачали хвилини на копіювання -артефактів, специфічних для машини. +Live-model Docker-ранери також bind-mount поточний checkout у режимі лише читання і +розгортають його в тимчасовий workdir усередині контейнера. Це зберігає runtime +image компактним, але все одно дозволяє запускати Vitest на вашому точному локальному source/config. +Крок staging пропускає великі локальні кеші та результати збірки app, такі як +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для app каталоги `.build` або +виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання +машинно-специфічних артефактів. Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали -реальні workers каналів Telegram/Discord тощо всередині контейнера. +реальні worker-процеси channel Telegram/Discord тощо всередині контейнера. `test:docker:live-models` усе ще запускає `pnpm test:live`, тож також передавайте -`OPENCLAW_LIVE_GATEWAY_*`, коли вам потрібно звузити або виключити gateway -live-покриття з цієї Docker lane. +`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити покриття gateway +live з цієї Docker lane. `test:docker:openwebui` — це smoke сумісності вищого рівня: він запускає -контейнер gateway OpenClaw з увімкненими HTTP endpoints, сумісними з OpenAI, -запускає закріплений контейнер Open WebUI проти цього gateway, виконує вхід через -Open WebUI, перевіряє, що `/api/models` містить `openclaw/default`, а потім надсилає +контейнер gateway OpenClaw з увімкненими OpenAI-compatible HTTP endpoints, +запускає pinned контейнер Open WebUI проти цього gateway, виконує вхід через +Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає реальний chat request через proxy `/api/chat/completions` Open WebUI. Перший запуск може бути помітно повільнішим, тому що Docker може потребувати завантаження -образу Open WebUI, а Open WebUI може потребувати завершення власного cold-start setup. -Ця lane очікує придатний ключ live-моделі, а `OPENCLAW_PROFILE_FILE` -(`~/.profile` типово) є основним способом надати його в Dockerized-запусках. -Успішні запуски виводять невеликий JSON-пейлоад на кшталт `{ "ok": true, "model": +image Open WebUI, а сам Open WebUI може завершувати власне cold-start налаштування. +Ця lane очікує наявний live model key, а `OPENCLAW_PROFILE_FILE` +(`~/.profile` за замовчуванням) — це основний спосіб надати його в Dockerized runs. +Успішні запуски виводять невеликий JSON payload на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує -реального облікового запису Telegram, Discord або iMessage. Він піднімає seeded Gateway -container, запускає другий контейнер, який породжує `openclaw mcp serve`, а потім -перевіряє виявлення маршрутизованих conversation, читання transcript, метадані вкладень, -поведінку черги live events, маршрутизацію outbound send і channel + -сповіщення про дозволи у стилі Claude через реальний stdio MCP bridge. Перевірка notification -безпосередньо досліджує сирі stdio MCP frames, щоб smoke перевіряв те, що -міст реально випромінює, а не лише те, що виводить конкретний клієнтський SDK. +реального облікового запису Telegram, Discord або iMessage. Він запускає seeded Gateway +container, стартує другий контейнер, який запускає `openclaw mcp serve`, а потім +перевіряє routed conversation discovery, читання transcript, metadata вкладень, +поведінку live event queue, outbound send routing і channel- та +permission-сповіщення в стилі Claude через реальний stdio MCP bridge. Перевірка notification +безпосередньо аналізує raw stdio MCP frames, тож smoke перевіряє те, що bridge +насправді випромінює, а не лише те, що випадково відображає певний client SDK. -Ручний ACP smoke plain-language thread (не CI): +Ручний ACP plain-language thread smoke (не CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Зберігайте цей скрипт для робочих процесів регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації ACP thread, тож не видаляйте його. +- Зберігайте цей скрипт для workflow регресій/налагодження. Він може знову знадобитися для валідації ACP thread routing, тож не видаляйте його. Корисні env vars: -- `OPENCLAW_CONFIG_DIR=...` (типово: `~/.openclaw`) монтується в `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (типово: `~/.openclaw/workspace`) монтується в `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (типово: `~/.profile`) монтується в `/home/node/.profile` і використовується перед запуском тестів -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (типово: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих установок CLI усередині Docker -- Зовнішні каталоги/файли auth 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_LIVE_REQUIRE_PROFILE_KEYS=1` щоб гарантувати, що облікові дані беруться з profile store (а не з 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_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих установок CLI усередині Docker +- Зовнішні CLI auth dirs/files під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед стартом тестів + - Каталоги за замовчуванням: `.minimax` + - Файли за замовчуванням: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` + - Для звужених запусків провайдерів монтуються лише потрібні dirs/files, визначені з `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_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб забезпечити надходження облікових даних із profile store (а не env) +- `OPENCLAW_OPENWEBUI_MODEL=...` для вибору моделі, яку gateway показує для smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...` для перевизначення prompt перевірки nonce, що використовується smoke Open WebUI +- `OPENWEBUI_IMAGE=...` для перевизначення pinned image tag Open WebUI ## Перевірка документації -Запускайте перевірки docs після редагування документації: `pnpm check:docs`. -Запускайте повну перевірку якорів Mintlify, коли вам також потрібні перевірки заголовків усередині сторінки: `pnpm docs:check-links:anchors`. +Після редагування документації запускайте перевірки docs: `pnpm check:docs`. +Запускайте повну валідацію якорів Mintlify, коли вам потрібні також перевірки заголовків у межах сторінки: `pnpm docs:check-links:anchors`. -## Офлайн-регресії (безпечні для CI) +## Офлайн-регресія (безпечна для CI) Це регресії «реального pipeline» без реальних провайдерів: -- Виклик інструментів gateway (mock OpenAI, реальний gateway + agent loop): `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 tool calling (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): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") -## Оцінювання надійності агентів (Skills) +## Оцінювання надійності agent (Skills) -У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агентів»: +У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності agent»: -- Mock-виклик інструментів через реальний gateway + agent loop (`src/gateway/gateway.test.ts`). -- Наскрізні потоки wizard, які перевіряють wiring session та ефекти config (`src/gateway/gateway.test.ts`). +- Mock tool-calling через реальний цикл gateway + agent (`src/gateway/gateway.test.ts`). +- Наскрізні потоки wizard, які перевіряють wiring сесій та ефекти config (`src/gateway/gateway.test.ts`). Чого все ще бракує для Skills (див. [Skills](/uk/tools/skills)): -- **Прийняття рішень:** коли Skills перелічені в prompt, чи обирає агент правильний skill (або уникає нерелевантних)? -- **Дотримання вимог:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/аргументи? -- **Контракти робочого процесу:** багатокрокові сценарії, що перевіряють порядок інструментів, перенесення історії session і межі sandbox. +- **Decisioning:** коли Skills перелічені в prompt, чи вибирає agent правильний skill (або уникає нерелевантних)? +- **Compliance:** чи читає agent `SKILL.md` перед використанням і чи дотримується обов’язкових кроків/args? +- **Workflow contracts:** багатокрокові сценарії, які перевіряють порядок tools, перенесення history між сесіями та межі sandbox. -Майбутні оцінювання мають спершу залишатися детермінованими: +Майбутні evals спершу мають залишатися детермінованими: -- Ранер сценаріїв із mock-провайдерами для перевірки викликів інструментів + порядку, читання skill-файлів і wiring session. -- Невеликий набір сценаріїв, сфокусованих на skills (використовувати чи уникати, gating, prompt injection). -- Необов’язкові live-оцінювання (opt-in, із керуванням через env) лише після того, як з’явиться безпечний для CI набір. +- Scenario runner з mock providers для перевірки tool calls + order, читання skill-файлів і wiring сесій. +- Невеликий набір сценаріїв, орієнтованих на skill (використовувати vs уникати, gating, prompt injection). +- Необов’язкові live evals (opt-in, env-gated) лише після того, як безпечний для CI набір буде готовий. -## Контрактні тести (форма plugin і channel) +## Contract-тести (форма plugin і channel) -Контрактні тести перевіряють, що кожен зареєстрований plugin і channel відповідає -своєму контракту інтерфейсу. Вони ітеруються по всіх виявлених plugins і запускають набір -перевірок форми та поведінки. Типова unit-lane `pnpm test` навмисно -пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, +Contract-тести перевіряють, що кожен зареєстрований plugin і channel відповідає +своєму interface contract. Вони перебирають усі знайдені plugins і запускають набір +перевірок форми та поведінки. Стандартна unit lane `pnpm test` навмисно +пропускає ці спільні seam- і smoke-файли; запускайте contract-команди явно, коли торкаєтеся спільних поверхонь channel або provider. ### Команди @@ -681,19 +681,19 @@ container, запускає другий контейнер, який пород - **plugin** - Базова форма plugin (id, name, capabilities) - **setup** - Контракт майстра налаштування -- **session-binding** - Поведінка прив’язки session +- **session-binding** - Поведінка прив’язування сесії - **outbound-payload** - Структура payload повідомлення -- **inbound** - Обробка вхідного повідомлення +- **inbound** - Обробка вхідних повідомлень - **actions** - Обробники дій channel - **threading** - Обробка ID thread -- **directory** - API каталогу/реєстру -- **group-policy** - Застосування групової політики +- **directory** - API каталогу/списку +- **group-policy** - Примусове застосування group policy ### Контракти статусу provider Розташовані в `src/plugins/contracts/*.contract.test.ts`. -- **status** - Проби статусу channel +- **status** - Перевірки status channel - **registry** - Форма реєстру plugin ### Контракти provider @@ -701,31 +701,31 @@ container, запускає другий контейнер, який пород Розташовані в `src/plugins/contracts/*.contract.test.ts`: - **auth** - Контракт потоку auth -- **auth-choice** - Вибір/селектор auth +- **auth-choice** - Вибір/відбір auth - **catalog** - API каталогу моделей - **discovery** - Виявлення plugin - **loader** - Завантаження plugin - **runtime** - Runtime provider -- **shape** - Форма/інтерфейс plugin +- **shape** - Форма/interface plugin - **wizard** - Майстер налаштування ### Коли запускати -- Після зміни export/subpath у plugin-sdk +- Після зміни exports або subpaths у plugin-sdk - Після додавання або зміни channel чи provider plugin - Після рефакторингу реєстрації або виявлення plugin -Контрактні тести запускаються в CI і не потребують реальних API-ключів. +Contract-тести запускаються в CI й не потребують реальних API keys. ## Додавання регресій (рекомендації) -Коли ви виправляєте проблему provider/model, виявлену в live: +Коли ви виправляєте проблему провайдера/моделі, виявлену в live: -- Якщо можливо, додайте безпечну для CI регресію (mock/stub provider або захопіть точне перетворення форми запиту) -- Якщо вона за своєю природою лише live (rate limits, політики auth), залишайте live-тест вузьким і opt-in через env vars -- Намагайтеся націлюватися на найменший рівень, який ловить баг: - - баг перетворення/повтору запиту провайдера → direct models test - - баг у pipeline gateway session/history/tool → gateway live smoke або безпечний для CI gateway mock test -- Захисне правило обходу SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль для кожного класу SecretRef із метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id сегментів обходу відхиляються. - - Якщо ви додаєте нову родину цілей SecretRef з `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було тихо пропустити. +- Додайте безпечну для CI регресію, якщо це можливо (mock/stub provider або захопіть точне перетворення форми запиту) +- Якщо це за своєю природою лише live-проблема (rate limits, політики auth), зберігайте live-тест вузьким і opt-in через env vars +- Надавайте перевагу найменшому шару, який виявляє баг: + - баг перетворення/повтору запиту provider → тест direct models + - баг pipeline gateway session/history/tool → live gateway smoke або безпечний для CI mock-тест gateway +- Guardrail обходу SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить один вибраний target на клас SecretRef із метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що traversal-segment exec ids відхиляються. + - Якщо ви додаєте нову родину target `includeInPlan` SecretRef у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target ids, щоб нові класи не можна було тихо пропустити. diff --git a/docs/uk/reference/test.md b/docs/uk/reference/test.md index 39f2dd28a..276fdc3a0 100644 --- a/docs/uk/reference/test.md +++ b/docs/uk/reference/test.md @@ -4,10 +4,10 @@ read_when: summary: Як локально запускати тести (vitest) і коли використовувати режими force/coverage title: Тести x-i18n: - generated_at: "2026-04-06T16:36:00Z" + generated_at: "2026-04-06T18:25:09Z" model: gpt-5.4 provider: openai - source_hash: a2a664aed9c2cc37144311d0257320268fe29d36da642775278f29bfc305bdeb + source_hash: daae3a499d78023da270e7d0e190c94a2eee2a3d42cd6c15cf551db48a18e6f4 source_path: reference/test.md workflow: 15 --- @@ -16,45 +16,45 @@ x-i18n: - Повний набір для тестування (набори, live, Docker): [Тестування](/uk/help/testing) -- `pnpm test:force`: Завершує будь-який завислий процес gateway, який утримує типовий control port, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, якщо попередній запуск gateway залишив порт 18789 зайнятим. -- `pnpm test:coverage`: Запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Глобальні пороги становлять 70% для lines/branches/functions/statements. Із покриття виключено entrypoints з великою інтеграційною складовою (CLI wiring, мости gateway/telegram, статичний сервер webchat), щоб зосередити ціль на логіці, придатній для unit-тестування. -- `pnpm test:coverage:changed`: Запускає unit coverage лише для файлів, змінених відносно `origin/main`. -- `pnpm test:changed`: розгортає змінені git-шляхи в обмежені lane-и Vitest, коли diff торкається лише routable файлів source/test. Зміни config/setup, як і раніше, повертаються до нативного запуску root projects, щоб у разі потреби зміни wiring запускали ширшу перевірку. -- `pnpm test`: спрямовує явно вказані цілі файлів/каталогів через обмежені lane-и Vitest. Запуски без цілей тепер виконують п’ять послідовних shard-конфігурацій (`vitest.full-core-unit.config.ts`, `vitest.full-core-runtime.config.ts`, `vitest.full-agentic.config.ts`, `vitest.full-auto-reply.config.ts`, `vitest.full-extensions.config.ts`) замість одного гігантського процесу root-project. -- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через окремі легкі lane-и, які залишають лише `test/setup.ts`, а resource-intensive випадки виконуються у наявних lane-ах. -- Вибрані допоміжні вихідні файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lane-ах, тож невеликі зміни в helper-ах не змушують повторно запускати важкі набори з runtime. -- `auto-reply` тепер також розбито на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness для reply не домінував над легшими top-level тестами status/token/helper. -- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в усіх конфігураціях репозиторію. +- `pnpm test:force`: Завершує будь-який завислий процес gateway, що утримує типовий control port, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували з уже запущеним екземпляром. Використовуйте це, якщо після попереднього запуску gateway порт 18789 залишився зайнятим. +- `pnpm test:coverage`: Запускає набір unit-тестів із V8 coverage (через `vitest.unit.config.ts`). Глобальні пороги становлять 70% для lines/branches/functions/statements. Із coverage виключено entrypoint-и з великою інтеграційною складовою (CLI wiring, gateway/telegram bridges, webchat static server), щоб ціль залишалася зосередженою на логіці, придатній для unit-тестування. +- `pnpm test:coverage:changed`: Запускає coverage unit-тестів лише для файлів, змінених відносно `origin/main`. +- `pnpm test:changed`: розгортає змінені git-шляхи у scoped lane-и Vitest, коли diff зачіпає лише routable файли вихідного коду/тестів. Зміни конфігурації/налаштування, як і раніше, повертаються до нативного запуску root projects, щоб за потреби зміни wiring перевірялися ширше. +- `pnpm test`: спрямовує явні цілі файлів/каталогів через scoped lane-и Vitest. Запуски без конкретних цілей тепер виконують шість послідовних shard-конфігурацій (`vitest.full-core-unit-src.config.ts`, `vitest.full-core-unit-support.config.ts`, `vitest.full-core-runtime.config.ts`, `vitest.full-agentic.config.ts`, `vitest.full-auto-reply.config.ts`, `vitest.full-extensions.config.ts`) замість одного гігантського процесу root-project. +- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через окремі легкі lane-и, у яких зберігається лише `test/setup.ts`, а важкі runtime-кейси залишаються у своїх наявних lane-ах. +- Вибрані допоміжні вихідні файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lane-ах, щоб невеликі зміни в helper-ах не запускали повторно важкі набори з runtime-backed тестами. +- `auto-reply` тепер також розбито на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими тестами верхнього рівня для status/token/helper. +- Базова конфігурація Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в усіх конфігураціях репозиторію. - `pnpm test:channels` запускає `vitest.channels.config.ts`. - `pnpm test:extensions` запускає `vitest.extensions.config.ts`. - `pnpm test:extensions`: запускає набори extension/plugin. -- `pnpm test:perf:imports`: вмикає звітність Vitest про тривалість import + import-breakdown, водночас зберігаючи маршрутизацію через обмежені lane-и для явно вказаних цілей файлів/каталогів. -- `pnpm test:perf:imports:changed`: те саме профілювання import, але лише для файлів, змінених відносно `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` виконує бенчмарк маршрутизованого шляху changed-mode проти нативного запуску root-project для того самого закоміченого git diff. -- `pnpm test:perf:changed:bench -- --worktree` виконує бенчмарк поточного набору змін worktree без попереднього коміту. -- `pnpm test:perf:profile:main`: записує профіль CPU для головного потоку Vitest (`.artifacts/vitest-main-profile`). -- `pnpm test:perf:profile:runner`: записує профілі CPU + heap для unit runner (`.artifacts/vitest-runner-profile`). -- Інтеграція gateway: вмикається за запитом через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`. -- `pnpm test:e2e`: Запускає наскрізні smoke-тести gateway (multi-instance WS/HTTP/node pairing). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=` і встановіть `OPENCLAW_E2E_VERBOSE=1` для докладних логів. -- `pnpm test:live`: Запускає live-тести provider-ів (minimax/zai). Потрібні API-ключі та `LIVE=1` (або provider-specific `*_LIVE_TEST=1`), щоб зняти пропуск. -- `pnpm test:docker:openwebui`: Запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потребує придатного ключа live model (наприклад, OpenAI у `~/.profile`), завантажує зовнішній образ Open WebUI і не вважається таким стабільним для CI, як звичайні набори unit/e2e. -- `pnpm test:docker:mcp-channels`: Запускає підготовлений контейнер Gateway і другий клієнтський контейнер, який запускає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання transcript, метадані вкладень, поведінку live event queue, маршрутизацію outbound send, а також сповіщення про channel + permission у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає необроблені кадри stdio MCP безпосередньо, щоб smoke-тест відображав те, що міст насправді надсилає. +- `pnpm test:perf:imports`: вмикає звітність Vitest за тривалістю імпорту та деталізацією імпортів, при цьому для явних цілей файлів/каталогів усе ще використовується маршрутизація через scoped lane-и. +- `pnpm test:perf:imports:changed`: те саме профілювання імпортів, але лише для файлів, змінених відносно `origin/main`. +- `pnpm test:perf:changed:bench -- --ref ` вимірює продуктивність маршрутизованого шляху changed-mode порівняно з нативним запуском root-project для того самого закоміченого git diff. +- `pnpm test:perf:changed:bench -- --worktree` вимірює продуктивність поточного набору змін у worktree без попереднього коміту. +- `pnpm test:perf:profile:main`: записує CPU-профіль для головного потоку Vitest (`.artifacts/vitest-main-profile`). +- `pnpm test:perf:profile:runner`: записує CPU- і heap-профілі для unit runner (`.artifacts/vitest-runner-profile`). +- Інтеграція gateway: вмикається через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`. +- `pnpm test:e2e`: Запускає наскрізні smoke-тести gateway (multi-instance WS/HTTP/node pairing). Типово використовує `threads` + `isolate: false` з адаптивною кількістю worker-ів у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=` і встановіть `OPENCLAW_E2E_VERBOSE=1` для докладних логів. +- `pnpm test:live`: Запускає live-тести провайдерів (minimax/zai). Потрібні API-ключі та `LIVE=1` (або специфічний для провайдера `*_LIVE_TEST=1`), щоб зняти пропуск. +- `pnpm test:docker:openwebui`: Запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксований чат через `/api/chat/completions`. Потрібен придатний ключ live-моделі (наприклад, OpenAI у `~/.profile`), завантажується зовнішній образ Open WebUI, і цей сценарій не вважається CI-stable, як звичайні набори unit/e2e. +- `pnpm test:docker:mcp-channels`: Запускає seeded Gateway container і другий client container, який піднімає `openclaw mcp serve`, а потім перевіряє routed conversation discovery, читання transcript, metadata вкладень, поведінку live event queue, маршрутизацію outbound send, а також сповіщення про channel + permission у стилі Claude через реальний stdio bridge. Перевірка сповіщень Claude читає сирі stdio MCP-кадри безпосередньо, щоб smoke відображав те, що bridge реально надсилає. ## Локальний PR gate -Для локальних перевірок PR land/gate виконайте: +Для локальних перевірок land/gate PR запустіть: - `pnpm check` - `pnpm build` - `pnpm test` - `pnpm check:docs` -Якщо `pnpm test` дає нестабільний результат на завантаженому хості, перезапустіть його один раз, перш ніж вважати це регресією, а потім ізолюйте проблему за допомогою `pnpm test `. Для хостів з обмеженою пам’яттю використовуйте: +Якщо `pnpm test` нестабільно відпрацьовує на навантаженому хості, перезапустіть його один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test `. Для хостів з обмеженою пам’яттю використовуйте: - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test` - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed` -## Бенч затримки моделі (локальні ключі) +## Бенчмарк затримки моделі (локальні ключі) Скрипт: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts) @@ -64,12 +64,12 @@ x-i18n: - Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY` - Типовий prompt: “Відповідай одним словом: ok. Без розділових знаків або зайвого тексту.” -Останній запуск (2025-12-31, 20 runs): +Останній запуск (2025-12-31, 20 запусків): - minimax median 1279ms (min 1114, max 2431) - opus median 2454ms (min 1224, max 3170) -## Бенч запуску CLI +## Бенчмарк запуску CLI Скрипт: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts) @@ -94,15 +94,15 @@ x-i18n: - `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status` - `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port` -- `all`: обидва набори preset-ів +- `all`: обидва preset-и -Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язковий `--cpu-prof-dir` / `--heap-prof-dir` записує профілі V8 для кожного запуску, тож вимірювання часу та збір профілів використовують один і той самий harness. +Вихідні дані містять `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують профілі V8 для кожного запуску, щоб вимірювання часу та захоплення профілів використовували один і той самий harness. -Угоди щодо збереженого виводу: +Умовні позначення для збережених результатів: - `pnpm test:startup:bench:smoke` записує цільовий smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json` -- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json` з використанням `runs=5` і `warmup=1` -- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json` з використанням `runs=5` і `warmup=1` +- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json` з `runs=5` і `warmup=1` +- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json` з `runs=5` і `warmup=1` Закомічений fixture: @@ -112,19 +112,19 @@ x-i18n: ## Onboarding E2E (Docker) -Docker необов’язковий; це потрібно лише для контейнеризованих smoke-тестів onboarding. +Docker необов’язковий; це потрібно лише для containerized smoke-тестів onboarding. -Повний cold-start flow у чистому Linux-контейнері: +Повний cold-start flow у чистому Linux container: ```bash scripts/e2e/onboard-docker.sh ``` -Цей скрипт керує інтерактивним wizard через pseudo-tty, перевіряє файли config/workspace/session, а потім запускає gateway і виконує `openclaw health`. +Цей скрипт проходить інтерактивний wizard через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`. -## Smoke-тест імпорту QR (Docker) +## Smoke-тест QR-імпорту (Docker) -Гарантує, що `qrcode-terminal` завантажується у підтримуваних Docker runtime Node (типово Node 24, сумісно з Node 22): +Гарантує, що `qrcode-terminal` завантажується в підтримуваних Docker Node runtime-ах (типово Node 24, сумісно з Node 22): ```bash pnpm test:docker:qr