From 2197737c0b7fed208000e23830b46d59aeffde91 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Fri, 24 Apr 2026 16:15:44 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/help/testing.md | 708 +++++++++++++++++---------------- docs/uk/plugins/google-meet.md | 153 +++---- 2 files changed, 432 insertions(+), 429 deletions(-) diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index ab6ab7883..21e2c7ff1 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -1,25 +1,25 @@ --- read_when: - Запуск тестів локально або в CI - - Додавання регресійних тестів для багів моделі/провайдера - - Налагодження поведінки Gateway + агента -summary: 'Набір для тестування: unit/e2e/live набори, Docker runners і що охоплює кожен тест' + - Додавання регресійних тестів для помилок моделей/провайдерів + - Налагодження поведінки Gateway + агентів +summary: 'Набір для тестування: набори unit/e2e/live, Docker-раннери та що саме охоплює кожен тест' title: Тестування x-i18n: - generated_at: "2026-04-24T06:45:24Z" + generated_at: "2026-04-24T16:12:18Z" model: gpt-5.4 provider: openai - source_hash: 6c88325e0edb49437e7faa2eaf730eb3be59054d8c4bb86e56a42bc39a29a2b1 + source_hash: 0d4f837faddc458509702b2a315d71d35740c01810ca76e40d652df54b09f38e source_path: help/testing.md workflow: 15 --- -OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір Docker runners. Цей документ — посібник «як ми тестуємо»: +OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір Docker-раннерів. Цей документ — посібник «як ми тестуємо»: - Що охоплює кожен набір (і що він навмисно _не_ охоплює). - Які команди запускати для типових сценаріїв роботи (локально, перед push, налагодження). - Як live-тести знаходять облікові дані та вибирають моделі/провайдерів. -- Як додавати регресійні тести для реальних проблем моделей/провайдерів. +- Як додавати регресійні тести для реальних проблем із моделями/провайдерами. ## Швидкий старт @@ -28,158 +28,158 @@ OpenClaw має три набори Vitest (unit/integration, e2e, live) і не - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` - Швидший локальний запуск повного набору на потужній машині: `pnpm test:max` - Прямий цикл спостереження Vitest: `pnpm test:watch` -- Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Під час ітерацій над однією помилкою спочатку віддавайте перевагу цільовим запускам. +- Пряме націлення на файл тепер також маршрутизує шляхи 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` +- QA-lane на основі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` Коли ви змінюєте тести або хочете більше впевненості: -- Coverage gate: `pnpm test:coverage` +- Gate покриття: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): -- Live-набір (моделі + перевірки tool/image для Gateway): `pnpm test:live` -- Тихо націлити один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Docker live model sweep: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер виконує текстовий хід плюс невелику перевірку у стилі читання файла. - Моделі, у metadata яких вказано вхід `image`, також виконують маленький хід із зображенням. +- Live-набір (моделі + перевірки інструментів/зображень Gateway): `pnpm test:live` +- Тихо націлитися на один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Docker sweep live-моделей: `pnpm test:docker:live-models` + - Кожна вибрана модель тепер виконує текстовий хід плюс невелику перевірку в стилі читання файла. + Моделі, чиї метадані оголошують вхід `image`, також виконують невеликий хід із зображенням. Вимкніть додаткові перевірки за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера. - - Покриття CI: щоденні `OpenClaw Scheduled Live And E2E Checks` і ручні + - Покриття в CI: щоденні `OpenClaw Scheduled Live And E2E Checks` і ручні `OpenClaw Release Checks` обидва викликають повторно використовуваний live/E2E workflow з - `include_live_suites: true`, що включає окремі Docker live model - matrix jobs, розподілені за провайдером. - - Для цільових повторних запусків у CI викликайте `OpenClaw Live And E2E Checks (Reusable)` - з `include_live_suites: true` і `live_models_only: true`. - - Додавайте нові секрети провайдерів із високим сигналом до `scripts/ci-hydrate-live-auth.sh`, - а також до `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` і його - запланованих/release викликачів. -- Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind` - - Запускає Docker live lane проти шляху Codex app-server, прив’язує синтетичний + `include_live_suites: true`, що включає окремі matrix jobs Docker 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` і його + scheduled/release викликачів. +- Smoke 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 binding Plugin, а не через ACP. -- Moonshot/Kimi перевірка вартості: якщо встановлено `MOONSHOT_API_KEY`, виконайте - `openclaw models list --provider moonshot --json`, а потім окремий + проходять через native binding плагіна, а не через ACP. +- 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, а - transcript помічника зберігає нормалізоване `usage.cost`. + проти `moonshot/kimi-k2.6`. Переконайтеся, що JSON повідомляє про Moonshot/K2.6 і що + transcript асистента зберігає нормалізоване `usage.cost`. -Порада: коли вам потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. +Порада: коли потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через env-змінні allowlist, описані нижче. -## QA-специфічні runners +## QA-специфічні раннери -Ці команди розташовані поруч з основними наборами тестів, коли вам потрібен реалізм QA-lab: +Ці команди використовуються поруч з основними наборами тестів, коли вам потрібен реалізм QA-lab: -CI запускає QA Lab в окремих workflows. `Parity gate` запускається для відповідних PR і -з ручного dispatch із mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на -`main` і з ручного dispatch із mock parity gate, live Matrix lane і -live Telegram lane під керуванням Convex як паралельними jobs. `OpenClaw Release Checks` -запускає ті самі lanes перед погодженням релізу. +CI запускає QA Lab в окремих workflow. `Parity gate` запускається на відповідних PR і +через ручний запуск із mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на +`main` і через ручний запуск із mock parity gate, live Matrix lane та +live Telegram lane під керуванням Convex як паралельними job. `OpenClaw Release Checks` +запускає ті самі lane перед погодженням релізу. - `pnpm openclaw qa suite` - - Запускає QA-сценарії на основі репозиторію безпосередньо на хості. + - Запускає сценарії QA на основі репозиторію безпосередньо на хості. - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими - Gateway workers. `qa-channel` за замовчуванням має concurrency 4 (обмежене - кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати - кількість workers, або `--concurrency 1` для старішого послідовного lane. - - Завершується з ненульовим кодом, якщо будь-який сценарій завершився невдало. Використовуйте `--allow-failures`, якщо + worker Gateway. `qa-channel` за замовчуванням використовує concurrency 4 (обмежено + кількістю вибраних сценаріїв). Використовуйте `--concurrency ` для налаштування + кількості worker, або `--concurrency 1` для старішого послідовного lane. + - Завершується з ненульовим кодом, якщо будь-який сценарій зазнає збою. Використовуйте `--allow-failures`, якщо вам потрібні артефакти без коду завершення з помилкою. - - Підтримує режими провайдерів `live-frontier`, `mock-openai` і `aimock`. + - Підтримує режими провайдера `live-frontier`, `mock-openai` і `aimock`. `aimock` запускає локальний сервер провайдера на основі AIMock для експериментального - покриття fixture і protocol mock без заміни lane `mock-openai`, - орієнтованого на сценарії. + покриття фікстурами та mock протоколу, не замінюючи сценарно-орієнтований + lane `mock-openai`. - `pnpm openclaw qa suite --runner multipass` - - Запускає той самий QA-набір усередині тимчасової Linux VM Multipass. + - Запускає той самий QA-набір усередині одноразової Linux VM Multipass. - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на хості. - Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`. - - Live-запуски пересилають підтримувані QA auth inputs, які практичні для guest: - ключі провайдерів на основі env, шлях до конфігурації QA live provider і `CODEX_HOME`, + - Live-запуски пересилають підтримувані вхідні дані автентифікації QA, практичні для гостьової системи: + ключі провайдера на основі env, шлях конфігурації live-провайдера QA і `CODEX_HOME`, якщо він присутній. - - Каталоги виводу мають залишатися в межах кореня репозиторію, щоб guest міг записувати назад через + - Каталоги виводу мають залишатися в межах кореня репозиторію, щоб гостьова система могла записувати назад через змонтований workspace. - - Записує звичайний QA-звіт і summary, а також логи Multipass у + - Записує звичайний QA-звіт + підсумок, а також журнали Multipass у `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - Запускає QA-сайт на основі Docker для QA-роботи в операторському стилі. - `pnpm test:docker:npm-onboard-channel-agent` - - Збирає npm tarball з поточного checkout, глобально встановлює його в - Docker, виконує неінтерактивне onboarding з API-ключем OpenAI, за замовчуванням налаштовує Telegram, - перевіряє, що увімкнення Plugin встановлює runtime dependencies на вимогу, - запускає doctor і виконує один локальний хід агента проти змоканого endpoint OpenAI. - - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити той самий lane - packaged install із Discord. + - Збирає npm tarball з поточного checkout, встановлює його глобально в + Docker, виконує неінтерактивний onboarding з API-ключем OpenAI, налаштовує Telegram + за замовчуванням, перевіряє, що ввімкнення Plugin встановлює runtime-залежності за потреби, + запускає doctor і виконує один локальний хід агента проти mock endpoint OpenAI. + - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити той самий + lane пакетного встановлення з 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 з цим встановленим пакетом як Gateway SUT. - За замовчуванням використовується `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`. - Використовує ті самі env-облікові дані Telegram або джерело облікових даних Convex, що й - `pnpm openclaw qa telegram`. Для автоматизації CI/release встановіть - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` разом із - `OPENCLAW_QA_CONVEX_SITE_URL` і секретом ролі. Якщо - `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі Convex присутні в CI, - Docker wrapper автоматично вибирає Convex. + `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 для maintainer + - GitHub Actions надає цей lane як ручний workflow для мейнтейнерів `NPM Telegram Beta E2E`. Він не запускається при merge. Workflow використовує середовище `qa-live-shared` і оренду CI-облікових даних Convex. - `pnpm test:docker:bundled-channel-deps` - - Пакує та встановлює поточний білд OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, а потім вмикає bundled channel/plugins через - редагування конфігурації. - - Перевіряє, що виявлення setup залишає runtime dependencies - неналаштованих plugins відсутніми, що перший налаштований запуск Gateway або doctor - встановлює runtime dependencies кожного bundled Plugin на вимогу, і що другий restart - не перевстановлює dependencies, які вже були активовані. - - Також встановлює відомий старіший npm baseline, вмикає Telegram перед запуском - `openclaw update --tag ` і перевіряє, що doctor кандидата - після оновлення відновлює runtime dependencies bundled channels без - postinstall repair з боку harness. + - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway + з налаштованим OpenAI, а потім вмикає bundled channel/Plugins через + редагування config. + - Перевіряє, що виявлення налаштування залишає відсутніми runtime-залежності + неналаштованих plugin, що перший налаштований запуск Gateway або doctor + встановлює runtime-залежності кожного bundled plugin за потреби, і що другий перезапуск + не перевстановлює залежності, які вже були активовані. + - Також встановлює відому старішу npm-базову версію, вмикає Telegram перед запуском + `openclaw update --tag ` і перевіряє, що + doctor після оновлення в кандидаті відновлює runtime-залежності bundled channel + без postinstall-відновлення з боку harness. - `pnpm openclaw qa aimock` - Запускає лише локальний сервер провайдера AIMock для прямого smoke-тестування протоколу. - `pnpm openclaw qa matrix` - - Запускає live QA lane Matrix проти тимчасового Tuwunel homeserver на основі Docker. - - Цей QA host наразі призначений лише для repo/dev. Packaged installs OpenClaw не постачають + - Запускає live QA-lane Matrix проти одноразового homeserver Tuwunel на основі Docker. + - Цей QA-хост наразі призначений лише для репозиторію/розробки. Пакетні встановлення OpenClaw не постачають `qa-lab`, тому вони не надають `openclaw qa`. - - Checkout-и репозиторію завантажують bundled runner напряму; окремий крок встановлення Plugin не потрібен. - - Надає три тимчасові користувачі Matrix (`driver`, `sut`, `observer`) плюс одну приватну кімнату, а потім запускає дочірній QA gateway з реальним Plugin Matrix як транспортом SUT. + - Checkout репозиторію завантажують bundled runner безпосередньо; окремий крок встановлення plugin не потрібен. + - Підготовлює трьох тимчасових користувачів Matrix (`driver`, `sut`, `observer`) плюс одну приватну кімнату, після чого запускає дочірній процес QA gateway з реальним Plugin Matrix як транспортом SUT. - За замовчуванням використовує закріплений стабільний образ Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Перевизначайте через `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, коли потрібно протестувати інший образ. - - Matrix не надає спільні прапорці джерела облікових даних, оскільки цей lane локально створює тимчасових користувачів. - - Записує Matrix QA report, summary, артефакт observed-events і комбінований журнал stdout/stderr у `.artifacts/qa-e2e/...`. + - Matrix не надає спільних прапорців джерела облікових даних, оскільки lane локально створює одноразових користувачів. + - Записує звіт Matrix QA, підсумок, артефакт observed-events і комбінований журнал виводу stdout/stderr у `.artifacts/qa-e2e/...`. - `pnpm openclaw qa telegram` - - Запускає live Telegram 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. - - Підтримує `--credential-source convex` для спільних пулових облікових даних. За замовчуванням використовуйте режим env або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. - - Завершується з ненульовим кодом, якщо будь-який сценарій завершився невдало. Використовуйте `--allow-failures`, якщо + - Підтримує `--credential-source convex` для спільних пулінгових облікових даних. За замовчуванням використовуйте режим env або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. + - Завершується з ненульовим кодом, якщо будь-який сценарій зазнає збою. Використовуйте `--allow-failures`, якщо вам потрібні артефакти без коду завершення з помилкою. - - Потребує двох різних ботів в одній приватній групі, причому бот SUT має мати username Telegram. - - Для стабільного спостереження bot-to-bot увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох ботів і переконайтеся, що бот driver може спостерігати трафік ботів у групі. - - Записує Telegram QA report, summary і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту надсилання driver до спостереженої відповіді SUT. + - Потребує двох різних ботів в одній приватній групі, причому бот SUT має мати Telegram username. + - Для стабільного спостереження bot-to-bot увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох ботів і переконайтеся, що бот driver може спостерігати за трафіком ботів у групі. + - Записує звіт Telegram QA, підсумок і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту на надсилання driver до спостереженої відповіді SUT. -Live transport lanes використовують один стандартний контракт, щоб нові транспорти не дрейфували: +Live transport lane мають спільний стандартний контракт, щоб нові транспорти не розходилися: -`qa-channel` залишається широким синтетичним QA-набором і не є частиною матриці покриття live transport. +`qa-channel` залишається широким синтетичним QA-набором і не входить до матриці покриття live transport. -| Lane | Canary | Блокування згадок | Блокування allowlist | Відповідь верхнього рівня | Відновлення після restart | Подальше повідомлення в треді | Ізоляція тредів | Спостереження за реакціями | Команда help | -| -------- | ------ | ----------------- | -------------------- | ------------------------- | ------------------------- | ----------------------------- | --------------- | -------------------------- | ------------ | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Lane | Канарейка | Контроль згадувань | Блокування allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Подальше повідомлення в потоці | Ізоляція потоку | Спостереження за реакціями | Команда довідки | +| -------- | --------- | ------------------ | -------------------- | ------------------------- | ----------------------------- | ------------------------------ | --------------- | -------------------------- | --------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | ### Спільні облікові дані Telegram через Convex (v1) Коли для `openclaw qa telegram` увімкнено `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`), -QA lab отримує ексклюзивну оренду з пулу на основі Convex, надсилає Heartbeat -цієї оренди під час роботи lane і звільняє оренду під час завершення роботи. +QA lab отримує ексклюзивну оренду з пулу на основі Convex, надсилає Heartbeat цієї +оренди, поки lane виконується, і звільняє оренду під час завершення роботи. -Довідковий scaffold проєкту Convex: +Довідкова структура проєкту Convex: - `qa/convex-credential-broker/` -Обов’язкові env vars: +Обов’язкові env-змінні: - `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад, `https://your-deployment.convex.site`) - Один секрет для вибраної ролі: @@ -187,9 +187,9 @@ QA lab отримує ексклюзивну оренду з пулу на ос - `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 vars: +Необов’язкові env-змінні: - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (за замовчуванням `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (за замовчуванням `30000`) @@ -199,12 +199,12 @@ QA lab отримує ексклюзивну оренду з пулу на ос - `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://`. -Адміністративні команди maintainer (додавання/видалення/перелік пулу) потребують +Адміністративні команди мейнтейнера (додавання/видалення/перелік пулу) потребують саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -Допоміжні команди CLI для maintainer: +CLI-хелпери для мейнтейнерів: ```bash pnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.json @@ -212,9 +212,9 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Використовуйте `--json` для машиночитаного виводу в скриптах і утилітах CI. +Використовуйте `--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 }` @@ -243,57 +243,57 @@ pnpm openclaw qa credentials remove --credential-id - `groupId` має бути рядком із числовим ідентифікатором чату Telegram. - `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє некоректні payload. -### Додавання каналу до QA +### Додавання channel до QA -Додавання каналу до markdown-системи QA потребує рівно двох речей: +Додавання channel до markdown-системи QA вимагає рівно двох речей: -1. Транспортного адаптера для каналу. -2. Набору сценаріїв, який перевіряє контракт каналу. +1. Транспортного адаптера для channel. +2. Набору сценаріїв, що перевіряє контракт channel. Не додавайте новий кореневий QA-командний простір верхнього рівня, якщо спільний хост `qa-lab` може керувати цим потоком. `qa-lab` керує спільною механікою хоста: -- кореневою командою `openclaw qa` -- запуском і завершенням набору -- паралелізмом workers -- записом артефактів -- генерацією звітів -- виконанням сценаріїв -- псевдонімами сумісності для старіших сценаріїв `qa-channel` +- кореневий простір команд `openclaw qa` +- запуск і завершення набору +- concurrency worker +- запис артефактів +- генерація звітів +- виконання сценаріїв +- aliases сумісності для старіших сценаріїв `qa-channel` -Runner plugins керують транспортним контрактом: +Runner-плагіни керують транспортним контрактом: - як `openclaw qa ` монтується під спільним коренем `qa` -- як Gateway налаштовується для цього транспорту +- як налаштовується gateway для цього транспорту - як перевіряється готовність -- як ін’єктуються вхідні події +- як інжектуються вхідні події - як спостерігаються вихідні повідомлення -- як надаються transcripts і нормалізований стан транспорту +- як надаються transcript і нормалізований стан транспорту - як виконуються дії на основі транспорту -- як обробляється скидання або очищення, специфічне для транспорту +- як обробляється скидання або очищення, специфічні для транспорту -Мінімальний поріг інтеграції для нового каналу: +Мінімальна планка впровадження для нового channel: -1. Зберігайте `qa-lab` як власника спільного кореня `qa`. -2. Реалізуйте transport runner на спільному seam хоста `qa-lab`. -3. Зберігайте специфічну для транспорту механіку всередині runner Plugin або harness каналу. -4. Монтуйте runner як `openclaw qa ` замість реєстрації конкуруючої кореневої команди. - Runner plugins мають оголошувати `qaRunners` у `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` з `runtime-api.ts`. - Зберігайте `runtime-api.ts` легким; ліниве виконання CLI і runner має залишатися за окремими entrypoints. -5. Створюйте або адаптуйте markdown-сценарії в тематичних каталогах `qa/scenarios/`. -6. Використовуйте загальні допоміжні функції сценаріїв для нових сценаріїв. -7. Зберігайте наявні псевдоніми сумісності працездатними, якщо тільки репозиторій не виконує навмисну міграцію. +1. Залишити `qa-lab` власником спільного кореня `qa`. +2. Реалізувати транспортний runner на шві спільного хоста `qa-lab`. +3. Тримати транспортно-специфічну механіку всередині runner-плагіна або harness channel. +4. Монтувати runner як `openclaw qa ` замість реєстрації конкуруючої кореневої команди. + Runner-плагіни повинні оголошувати `qaRunners` у `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. + Тримайте `runtime-api.ts` легким; лінивий CLI і виконання runner мають залишатися за окремими entrypoint. +5. Створювати або адаптувати markdown-сценарії в тематичних каталогах `qa/scenarios/`. +6. Використовувати узагальнені helper для нових сценаріїв. +7. Зберігати робочими наявні aliases сумісності, якщо в репозиторії не виконується навмисна міграція. -Правило ухвалення рішення є суворим: +Правило прийняття рішення суворе: - Якщо поведінку можна виразити один раз у `qa-lab`, розміщуйте її в `qa-lab`. -- Якщо поведінка залежить від одного транспортного каналу, зберігайте її в runner Plugin або harness цього Plugin. -- Якщо сценарію потрібна нова можливість, яку може використовувати більше ніж один канал, додайте загальну допоміжну функцію замість специфічної для каналу гілки в `suite.ts`. -- Якщо поведінка має сенс лише для одного транспорту, зберігайте сценарій специфічним для цього транспорту і явно вказуйте це в контракті сценарію. +- Якщо поведінка залежить від одного channel transport, залишайте її в цьому runner-плагіні або harness плагіна. +- Якщо сценарію потрібна нова можливість, яку може використовувати більше ніж один channel, додайте узагальнений helper замість channel-специфічної гілки в `suite.ts`. +- Якщо поведінка має сенс лише для одного транспорту, залишайте сценарій транспортно-специфічним і явно зазначайте це в контракті сценарію. -Бажані назви загальних допоміжних функцій для нових сценаріїв: +Бажані назви узагальнених helper для нових сценаріїв: - `waitForTransportReady` - `waitForChannelReady` @@ -308,7 +308,7 @@ Runner plugins керують транспортним контрактом: - `formatTransportTranscript` - `resetTransport` -Псевдоніми сумісності залишаються доступними для наявних сценаріїв, зокрема: +Aliases сумісності залишаються доступними для наявних сценаріїв, зокрема: - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -316,95 +316,97 @@ Runner plugins керують транспортним контрактом: - `formatConversationTranscript` - `resetBus` -Нова робота над каналами має використовувати загальні назви допоміжних функцій. -Псевдоніми сумісності існують, щоб уникнути міграції одним днем, а не як модель для +Нова робота з channel повинна використовувати узагальнені назви helper. +Aliases сумісності існують, щоб уникнути міграції одним днем, а не як модель для створення нових сценаріїв. ## Набори тестів (що де запускається) Сприймайте набори як «зростання реалізму» (і зростання нестабільності/вартості): -### Unit / integration (за замовчуванням) +### Unit / integration (типово) - Команда: `pnpm test` -- Конфігурація: ненаправлені запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shards у конфігурації для кожного проєкту для паралельного планування -- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і включені до allowlist node-тести `ui`, що покриваються `vitest.unit.config.ts` +- Конфігурація: ненаправлені запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shard у конфігурації per-project для паралельного планування +- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і дозволені node-тести `ui`, що покриваються `vitest.unit.config.ts` - Обсяг: - Чисті unit-тести - - In-process integration-тести (auth Gateway, маршрутизація, tooling, парсинг, конфігурація) - - Детерміновані регресії для відомих багів + - Інтеграційні тести в межах процесу (автентифікація gateway, маршрутизація, інструментарій, парсинг, config) + - Детерміновані регресії для відомих помилок - Очікування: - Запускається в CI - Реальні ключі не потрібні - Має бути швидким і стабільним - - Ненаправлений `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` project graph, тому що цикл спостереження з кількома 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 зачіпає лише source/test-файли, які можна маршрутизувати; редагування config/setup усе ще повертаються до широкого повторного запуску root project. - `pnpm check:changed` — це звичайний розумний локальний gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, metadata релізу та tooling, а потім запускає відповідні lanes typecheck/lint/test. Зміни публічного Plugin SDK і plugin-contract включають один прохід валідації extension, тому що extensions залежать від цих core-контрактів. Підвищення версії лише в metadata релізу запускають цільові перевірки version/config/root-dependency замість повного набору, із захистом, який відхиляє зміни пакета поза полем версії верхнього рівня. - Легкі за імпортами unit-тести з agents, commands, plugins, допоміжних функцій auto-reply, `plugin-sdk` та подібних чисто утилітарних зон маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. - Вибрані вихідні допоміжні файли `plugin-sdk` і `commands` також зіставляють запуски в режимі changed з явними сусідніми тестами в цих легких lanes, тому редагування допоміжних функцій уникають повторного запуску повного важкого набору для цього каталогу. - `auto-reply` має три окремі bucket: допоміжні функції верхнього рівня core, integration-тести верхнього рівня `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. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати не пов’язані набори. - `pnpm test --watch` усе ще використовує native граф проєктів root `vitest.config.ts`, оскільки цикл watch із multi-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` — звичайний розумний локальний gate для вузької роботи. Він класифікує diff на core, тести core, extensions, тести extension, apps, docs, метадані релізу та tooling, а потім запускає відповідні lane typecheck/lint/test. Зміни в публічному Plugin SDK і plugin-contract включають один прохід валідації extension, тому що extensions залежать від цих контрактів core. Підвищення версії лише в метаданих релізу запускають цільові перевірки version/config/root-dependency замість повного набору, із guard, що відхиляє зміни пакета поза полем версії верхнього рівня. - Легкі щодо імпорту 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-тести в цих легких lane, тож зміни helper уникають повторного запуску повного важкого набору для цього каталогу. - `auto-reply` має три виділені buckets: helper core верхнього рівня, інтеграційні тести верхнього рівня `reply.*` і піддерево `src/auto-reply/reply/**`. Це не дає найважчій роботі harness reply потрапляти на дешеві тести status/chunk/token. - - Коли ви змінюєте входи виявлення message-tool або контекст runtime Compaction, зберігайте обидва рівні покриття. - - Додавайте цільові допоміжні регресії для чистих меж маршрутизації та нормалізації. - - Підтримуйте в хорошому стані integration-набори embedded runner: + - Коли ви змінюєте вхідні дані виявлення message-tool або runtime + context Compaction, зберігайте обидва рівні покриття. + - Додавайте сфокусовані helper-регресії для чистих меж + маршрутизації та нормалізації. + - Підтримуйте інтеграційні набори embedded runner у здоровому стані: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` і `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Ці набори перевіряють, що scoped ids і поведінка compaction, як і раніше, проходять - через реальні шляхи `run.ts` / `compact.ts`; тести лише допоміжних функцій не є достатньою заміною для цих integration-шляхів. + - Ці набори перевіряють, що scoped id і поведінка Compaction, як і раніше, проходять + через реальні шляхи `run.ts` / `compact.ts`; тести лише для helper + не є достатньою заміною цим інтеграційним шляхам. - - - Базова конфігурація Vitest за замовчуванням використовує `threads`. + + - Базова конфігурація Vitest типово використовує `threads`. - Спільна конфігурація Vitest фіксує `isolate: false` і використовує - неізольований runner у root projects, а також у конфігураціях e2e і live. - - Root UI lane зберігає своє налаштування `jsdom` і optimizer, але теж працює на + неізольований runner у root project, а також у конфігураціях e2e і live. + - Lane root UI зберігає своє налаштування `jsdom` і optimizer, але теж працює на спільному неізольованому runner. - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` зі спільної конфігурації Vitest. - - `scripts/run-vitest.mjs` за замовчуванням додає `--no-maglev` для дочірніх Node process Vitest, + - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. - Встановіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною - поведінкою V8. + Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. - - - `pnpm changed:lanes` показує, які архітектурні lanes запускає diff. - - Pre-commit hook відповідає лише за форматування. Він повторно додає відформатовані файли до staging - і не запускає lint, typecheck або тести. - - Явно запускайте `pnpm check:changed` перед передачею роботи або push, коли - вам потрібен розумний локальний gate. Зміни публічного Plugin SDK і plugin-contract + + - `pnpm changed:lanes` показує, які архітектурні lane запускає diff. + - Хук pre-commit відповідає лише за форматування. Він повторно додає відформатовані файли до stage і + не запускає lint, typecheck або тести. + - Явно запускайте `pnpm check:changed` перед передачею роботи або push, коли вам + потрібен розумний локальний gate. Зміни в публічному Plugin SDK і plugin-contract включають один прохід валідації extension. - - `pnpm test:changed` маршрутизує через scoped lanes, коли змінені шляхи - чітко відповідають меншому набору. + - `pnpm test:changed` маршрутизує через scoped lane, коли змінені шляхи + однозначно відповідають меншому набору. - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, - лише з вищою межею для workers. - - Автомасштабування локальних workers навмисно консервативне й зменшує навантаження, + лише з вищою межею worker. + - Автомасштабування локальних worker навмисно консервативне і зменшує навантаження, коли середнє навантаження хоста вже високе, тому кілька одночасних - запусків Vitest за замовчуванням завдають менше шкоди. - - Базова конфігурація Vitest позначає проєкти/конфігураційні файли як - `forceRerunTriggers`, щоб повторні запуски в режимі changed залишалися коректними, коли змінюється зв’язування тестів. - - Конфігурація зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних - хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете - одну явну локацію кешу для прямого профілювання. + запусків Vitest типово завдають менше шкоди. + - Базова конфігурація Vitest позначає файли projects/config як + `forceRerunTriggers`, щоб повторні запуски в changed-mode залишалися коректними, коли змінюється зв’язування тестів. + - Конфігурація зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на + підтримуваних хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо + хочете один явний шлях кешу для прямого профілювання. - - - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпорту, а також + + - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпорту плюс вивід import-breakdown. - - `pnpm test:perf:imports:changed` обмежує той самий профілювальний перегляд - файлами, зміненими відносно `origin/main`. + - `pnpm test:perf:imports:changed` обмежує той самий режим профілювання + файлами, зміненими від `origin/main`. - Коли один гарячий тест усе ще витрачає більшість часу на стартові імпорти, - тримайте важкі залежності за вузьким локальним seam `*.runtime.ts` і - мокайте цей seam напряму замість deep-import runtime helpers - лише для того, щоб передати їх через `vi.mock(...)`. + тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і + мокуйте цей шов безпосередньо замість глибокого імпорту runtime-helper лише + для того, щоб передати їх через `vi.mock(...)`. - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований - `test:changed` із native root-project path для цього закоміченого diff - і виводить wall time плюс macOS max RSS. - - `pnpm test:perf:changed:bench -- --worktree` вимірює поточне брудне дерево, - маршрутизуючи список змінених файлів через + `test:changed` із native шляхом root-project для цього закоміченого + diff і виводить wall time плюс максимальний RSS на macOS. + - `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного + брудного дерева, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і root-конфігурацію Vitest. - - `pnpm test:perf:profile:main` записує CPU profile основного потоку для - накладних витрат запуску та transform у Vitest/Vite. - - `pnpm test:perf:profile:runner` записує CPU+heap profiles runner для + - `pnpm test:perf:profile:main` записує профіль CPU головного потоку для + накладних витрат запуску та трансформації Vitest/Vite. + - `pnpm test:perf:profile:runner` записує профілі CPU+heap runner для unit-набору з вимкненим файловим паралелізмом. @@ -414,273 +416,273 @@ Runner plugins керують транспортним контрактом: - Команда: `pnpm test:stability:gateway` - Конфігурація: `vitest.gateway.config.ts`, примусово один worker - Обсяг: - - Запускає реальний loopback Gateway з увімкненою діагностикою за замовчуванням - - Пропускає синтетичне навантаження повідомленнями Gateway, пам’яттю та великими payload через шлях діагностичних подій - - Виконує запит `diagnostics.stability` через Gateway WS RPC - - Покриває допоміжні функції збереження пакета діагностики стабільності - - Перевіряє, що recorder залишається обмеженим, синтетичні зразки RSS лишаються в межах бюджету навантаження, а глибини черг на рівні сесій знову зменшуються до нуля + - Запускає реальний loopback Gateway з diagnostics, увімкненими за замовчуванням + - Проганяє синтетичне churn повідомлень gateway, пам’яті та великих payload через діагностичний шлях подій + - Виконує запити до `diagnostics.stability` через WS RPC Gateway + - Покриває helper збереження пакета діагностичної стабільності + - Перевіряє, що recorder залишається обмеженим, синтетичні зразки RSS залишаються в межах бюджету тиску, а глибини черг на рівні сесії повертаються до нуля - Очікування: - Безпечно для CI і без ключів - - Вузький lane для подальшого відстеження регресій стабільності, а не заміна повному набору Gateway + - Вузький lane для подальшої роботи над регресіями стабільності, а не заміна повного набору Gateway ### E2E (gateway smoke) - Команда: `pnpm test:e2e` - Конфігурація: `vitest.e2e.config.ts` -- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled Plugin у `extensions/` +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled-plugin у `extensions/` - Типові параметри runtime: - - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. - - Використовує адаптивну кількість workers (CI: до 2, локально: 1 за замовчуванням). - - За замовчуванням запускається в тихому режимі, щоб зменшити накладні витрати на консольний I/O. + - Використовує `threads` у Vitest з `isolate: false`, як і решта репозиторію. + - Використовує адаптивних worker (CI: до 2, локально: 1 за замовчуванням). + - За замовчуванням працює в тихому режимі, щоб зменшити накладні витрати на I/O консолі. - Корисні перевизначення: - - `OPENCLAW_E2E_WORKERS=` щоб примусово задати кількість workers (обмежено 16). - - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний консольний вивід. + - `OPENCLAW_E2E_WORKERS=` щоб примусово задати кількість worker (обмежено 16). + - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний вивід у консоль. - Обсяг: - - Наскрізна поведінка кількох екземплярів Gateway - - Поверхні WebSocket/HTTP, pairing Node і складніша мережна взаємодія + - Наскрізна поведінка gateway з кількома інстансами + - Поверхні WebSocket/HTTP, pairing Node і важча мережева взаємодія - Очікування: - Запускається в CI (коли ввімкнено в pipeline) - Реальні ключі не потрібні - Більше рухомих частин, ніж у unit-тестах (може бути повільніше) -### E2E: smoke для backend OpenShell +### E2E: smoke OpenShell backend - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` - Обсяг: - - Запускає ізольований Gateway OpenShell на хості через Docker + - Запускає ізольований gateway OpenShell на хості через Docker - Створює sandbox із тимчасового локального Dockerfile - - Перевіряє backend OpenShell OpenClaw через реальні `sandbox ssh-config` + виконання SSH - - Перевіряє поведінку файлової системи в remote-canonical режимі через fs bridge sandbox + - Перевіряє backend OpenShell в OpenClaw через реальні `sandbox ssh-config` + SSH exec + - Перевіряє поведінку файлової системи remote-canonical через міст fs sandbox - Очікування: - - Лише за явним увімкненням; не входить до типового запуску `pnpm test:e2e` - - Потребує локального CLI `openshell` і працездатного Docker daemon - - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестові gateway і sandbox + - Лише opt-in; не входить до типового запуску `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 або wrapper script + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб указати нестандартний бінарний файл CLI або wrapper-скрипт ### 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`) +- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести bundled-plugin у `extensions/` +- Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) - Обсяг: - «Чи справді цей провайдер/модель працює _сьогодні_ з реальними обліковими даними?» - - Виявлення змін формату провайдера, особливостей виклику tools, проблем auth і поведінки rate limit + - Виявлення змін формату провайдера, особливостей виклику інструментів, проблем автентифікації та поведінки rate limit - Очікування: - - Навмисно нестабільні для CI (реальні мережі, реальні політики провайдерів, квоти, збої) - - Коштують грошей / використовують rate limits + - За задумом не є стабільним для CI (реальні мережі, реальні політики провайдерів, квоти, збої) + - Коштує грошей / використовує rate limit - Краще запускати звужені підмножини, а не «все» -- Live-запуски використовують `~/.profile`, щоб підхопити відсутні API-ключі. -- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють матеріали config/auth до тимчасового тестового home, щоб unit-fixtures не могли змінювати ваш реальний `~/.openclaw`. -- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли вам навмисно потрібно, щоб live-тести використовували ваш реальний home-каталог. -- `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. +- Live-запуски читають `~/.profile`, щоб підхопити відсутні API-ключі. +- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють config/auth-матеріали до тимчасового тестового 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`) або використовуйте перевизначення per-live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спроби при відповідях rate limit. - Вивід прогресу/Heartbeat: - - Live-набори тепер виводять рядки прогресу в stderr, тож довгі виклики провайдерів помітно активні, навіть коли захоплення консолі Vitest працює в тихому режимі. - - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, тому рядки прогресу провайдера/Gateway одразу транслюються під час live-запусків. - - Налаштовуйте Heartbeat для прямих моделей через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштовуйте Heartbeat для Gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - 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 / pairing: додайте `pnpm test:e2e` -- Налагоджуєте «мій бот не працює» / специфічні для провайдера збої / виклик tools: запускайте звужений `pnpm test:live` +- Редагування логіки/тестів: запустіть `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) +- Зміни в мережевій взаємодії gateway / WS protocol / pairing: додайте `pnpm test:e2e` +- Налагодження «мій бот не працює» / специфічних збоїв провайдера / виклику інструментів: запускайте звужений `pnpm test:live` -## Live-тести (що взаємодіють із мережею) +## Live-тести (що торкаються мережі) -Для live-матриці моделей, smoke-тестів backend CLI, smoke-тестів ACP, harness -Codex app-server і всіх live-тестів media providers (Deepgram, BytePlus, ComfyUI, image, -music, video, media harness) — а також для обробки облікових даних у live-запусках — див. +Для live-матриці моделей, smoke backend CLI, smoke ACP, harness app-server Codex +і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, image, +music, video, media harness) — а також обробки облікових даних для live-запусків — див. [Тестування — live-набори](/uk/help/testing-live). -## Docker runners (необов’язкові перевірки «працює в Linux») +## Docker-раннери (необов’язкові перевірки «працює в Linux») -Ці Docker runners поділяються на дві категорії: +Ці Docker-раннери поділяються на дві категорії: -- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл з profile-key усередині Docker image репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог config і workspace (і використовують `~/.profile`, якщо його змонтовано). Відповідні локальні entrypoints: `test:live:models-profiles` і `test:live:gateway-profiles`. -- Docker live runners за замовчуванням мають меншу межу smoke, щоб повний Docker sweep залишався практичним: +- Раннери live-моделей: `test:docker:live-models` і `test:docker:live-gateway` запускають лише свій відповідний live-файл із ключем профілю всередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог config і workspace (і читають `~/.profile`, якщо його змонтовано). Відповідні локальні entrypoint: `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, коли + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env-змінні, коли вам явно потрібне більше вичерпне сканування. -- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, а потім повторно використовує його для двох live Docker lanes. Він також збирає один спільний image `scripts/e2e/Dockerfile` через `test:docker:e2e-build` і повторно використовує його для container smoke runners E2E, які перевіряють зібраний застосунок. -- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `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` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. +- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, а потім повторно використовує його для двох Docker lane live. Він також збирає один спільний образ `scripts/e2e/Dockerfile` через `test:docker:e2e-build` і повторно використовує його для smoke-раннерів контейнерів E2E, що перевіряють зібраний застосунок. +- Smoke-раннери контейнерів: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `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` запускають один або більше реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. -Docker runners для live-моделей також bind-mount лише потрібні CLI auth homes (або всі підтримувані, якщо запуск не звужено), а потім копіюють їх у home контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без зміни host auth store: +Docker-раннери live-моделей також bind-mount лише потрібні auth-home CLI (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у home контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без зміни auth-store хоста: - Прямі моделі: `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`) -- Smoke для backend CLI: `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`) +- CLI backend smoke: `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`) -- 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`) -- 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`, пропустіть перебудову на хості через `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` повертає bundled image providers замість зависання. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть збірку на хості через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` із зібраного Docker image через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Docker smoke для інсталятора: `bash scripts/test-install-sh-docker.sh` використовує один кеш npm для своїх контейнерів root, update і direct-npm. Update smoke за замовчуванням використовує npm `latest` як стабільний baseline перед оновленням до tarball кандидата. Перевірки non-root installer зберігають ізольований кеш npm, щоб записи кешу, які належать root, не маскували поведінку локального встановлення користувача. Встановіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати кеш root/update/direct-npm між локальними повторними запусками. -- CI Install Smoke пропускає дубльоване пряме глобальне оновлення npm через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. -- Мережна взаємодія 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`, потім примусово викликає відхилення схеми провайдера і перевіряє, що необроблена деталь з’являється в логах Gateway. -- Міст MCP channel (seeded Gateway + stdio bridge + smoke необробленого кадру notification Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) -- Інструменти MCP bundle Pi (реальний сервер stdio MCP + smoke allow/deny вбудованого профілю Pi): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Live smoke Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Майстер onboarding (TTY, повне scaffold): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) +- Smoke onboarding/channel/agent для npm tarball: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через onboarding із посиланням на env плюс Telegram за замовчуванням, перевіряє, що doctor відновлює runtime-залежності активованого plugin, і виконує один mock-хід агента OpenAI. Щоб повторно використати попередньо зібраний tarball, установіть `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, щоб пропустити перебудову на хості — `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0`, а щоб змінити channel — `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Smoke глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає bundled image-провайдерів замість зависання. Щоб повторно використати попередньо зібраний tarball, установіть `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, щоб пропустити збірку на хості — `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0`, або скопіюйте `dist/` із зібраного Docker image через `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, щоб записи 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`. +- Мережева взаємодія Gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) +- Регресія мінімального reasoning для `web_search` в OpenAI Responses: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає mock-сервер OpenAI через Gateway, перевіряє, що `web_search` підвищує `reasoning.effort` з `minimal` до `low`, потім примусово викликає відхилення схеми провайдера і перевіряє, що сирі деталі з’являються в журналах Gateway. +- Міст channel MCP (seeded Gateway + stdio bridge + raw smoke notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) +- Інструменти MCP у Pi bundle (реальний stdio MCP-сервер + smoke allow/deny для вбудованого профілю Pi): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) - Очищення MCP Cron/subagent (реальний Gateway + завершення дочірнього stdio MCP після ізольованих запусків cron і одноразового subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (smoke встановлення + псевдонім `/plugin` + семантика restart для bundled Claude): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) -- Smoke оновлення Plugin без змін: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Smoke metadata перезавантаження конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) -- Runtime deps bundled Plugin: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий Docker runner image, один раз збирає і пакує OpenClaw на хості, а потім монтує цей tarball у кожен сценарій встановлення Linux. Повторно використовуйте image через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропустіть перебудову на хості після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть наявний tarball через `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. -- Звужуйте runtime deps bundled Plugin під час ітерацій, вимикаючи непов’язані сценарії, наприклад: +- Plugins (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 метаданих перезавантаження config: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) +- Runtime-залежності bundled plugin: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий runner image Docker, один раз збирає й пакує OpenClaw на хості, а потім монтує цей tarball у кожен сценарій встановлення Linux. Повторно використовуйте image через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропустіть перебудову на хості після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть наявний tarball через `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний агрегат Docker попередньо пакує цей tarball один раз, а потім розшардовує перевірки bundled channel на незалежні lane; використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити матрицю channel під час прямого запуску bundled lane. +- Під час ітерацій звужуйте перевірки runtime-залежностей bundled 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`. -Щоб вручну попередньо зібрати і повторно використовувати спільний image built-app: +Щоб вручну попередньо зібрати та повторно використати спільний image built-app: ```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 ``` -Специфічні для набору перевизначення image, такі як `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, якщо встановлені. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний image, скрипти завантажують його, якщо його ще немає локально. Docker-тести QR та інсталятора зберігають власні Dockerfile, оскільки вони перевіряють поведінку пакета/встановлення, а не спільний runtime built-app. +Перевизначення image для конкретних наборів, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, якщо встановлені. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` указує на віддалений спільний image, скрипти завантажують його, якщо він ще не доступний локально. Docker-тести QR і інсталятора зберігають власні Dockerfile, оскільки вони перевіряють поведінку пакета/встановлення, а не runtime спільного built-app. -Docker runners для live-моделей також монтують поточний checkout лише для читання і -розміщують його в тимчасовому workdir усередині контейнера. Це зберігає runtime -image компактним, водночас усе ще запускаючи Vitest проти вашого точного локального source/config. -Крок staging пропускає великі локальні кеші та результати збірки застосунків, такі як +Docker-раннери live-моделей також bind-mount поточний checkout лише для читання і +розгортають його в тимчасовий workdir усередині контейнера. Це зберігає runtime +image компактним, але водночас дозволяє запускати Vitest точно на вашому локальному source/config. +Крок розгортання пропускає великі локальні cache і результати збірки застосунків, такі як `.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні для app каталоги `.build` або виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання артефактів, специфічних для машини. -Вони також установлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-probes Gateway не запускали -реальні workers каналів Telegram/Discord тощо всередині контейнера. -`test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте -`OPENCLAW_LIVE_GATEWAY_*`, коли вам потрібно звузити або виключити покриття -live Gateway із цього Docker lane. -`test:docker:openwebui` — це smoke вищого рівня для сумісності: він запускає -контейнер Gateway OpenClaw з увімкненими HTTP endpoint, сумісними з OpenAI, -запускає контейнер Open WebUI із закріпленою версією проти цього Gateway, входить -через Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає -реальний запит чату через proxy Open WebUI `/api/chat/completions`. +Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-probe Gateway не запускали +реальні worker channel Telegram/Discord тощо всередині контейнера. +`test:docker:live-models` усе ще запускає `pnpm test:live`, тож також передавайте +`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити live-покриття +Gateway з цього Docker lane. +`test:docker:openwebui` — це smoke-перевірка сумісності вищого рівня: вона запускає +контейнер gateway OpenClaw з увімкненими HTTP-endpoint, сумісними з OpenAI, +запускає закріплений контейнер Open WebUI проти цього gateway, входить через +Open WebUI, перевіряє, що `/api/models` надає `openclaw/default`, а потім надсилає +реальний chat-запит через проксі Open WebUI `/api/chat/completions`. Перший запуск може бути помітно повільнішим, оскільки Docker може потребувати завантаження -image Open WebUI, а самому Open WebUI може знадобитися завершити власне налаштування холодного старту. +image Open WebUI, а самому Open WebUI може знадобитися завершити власне холодне стартове налаштування. Цей lane очікує придатний ключ live-моделі, а `OPENCLAW_PROFILE_FILE` -(за замовчуванням `~/.profile`) — основний спосіб надати його в Docker-запусках. -Успішні запуски виводять невеликий JSON payload, наприклад `{ "ok": true, "model": +(за замовчуванням `~/.profile`) є основним способом надати його в Docker-запусках. +Успішні запуски виводять невеликий JSON payload на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує реального облікового запису Telegram, Discord або iMessage. Він запускає seeded Gateway -container, запускає другий container, який породжує `openclaw mcp serve`, а потім -перевіряє маршрутизоване виявлення conversation, читання transcript, metadata вкладень, -поведінку черги live events, маршрутизацію вихідних надсилань, а також сповіщення про channel + -дозволи в стилі Claude через реальний stdio MCP bridge. Перевірка сповіщень -безпосередньо аналізує необроблені кадри stdio MCP, тож smoke перевіряє те, що -міст реально надсилає, а не лише те, що випадково показує конкретний SDK клієнта. -`test:docker:pi-bundle-mcp-tools` є детермінованим і не потребує -ключа live-моделі. Він збирає Docker image репозиторію, запускає реальний сервер-зонд stdio MCP -усередині контейнера, матеріалізує цей сервер через runtime вбудованого bundle MCP Pi, -виконує tool, а потім перевіряє, що `coding` і `messaging` зберігають -tools `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх відфільтровують. -`test:docker:cron-mcp-cleanup` є детермінованим і не потребує ключа live-моделі. -Він запускає seeded Gateway з реальним сервером-зондом stdio MCP, виконує -ізольований хід cron і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, +контейнер, запускає другий контейнер, який піднімає `openclaw mcp serve`, а потім +перевіряє маршрутизоване виявлення conversation, читання transcript, метадані вкладень, +поведінку черги live-подій, маршрутизацію вихідного надсилання та сповіщення channel + +permission у стилі Claude через реальний міст stdio MCP. Перевірка сповіщень +безпосередньо аналізує сирі кадри stdio MCP, тож smoke перевіряє те, що +міст справді видає, а не лише те, що випадково показує конкретний SDK клієнта. +`test:docker:pi-bundle-mcp-tools` детермінований і не потребує ключа live-моделі. +Він збирає Docker image репозиторію, запускає реальний stdio MCP probe-сервер +усередині контейнера, матеріалізує цей сервер через вбудований runtime MCP Pi bundle, +виконує інструмент, а потім перевіряє, що `coding` і `messaging` зберігають +інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх відфільтровують. +`test:docker:cron-mcp-cleanup` детермінований і не потребує ключа live-моделі. +Він запускає seeded Gateway з реальним stdio MCP probe-сервером, виконує +ізольований хід Cron і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, що дочірній процес MCP завершується після кожного запуску. -Ручний smoke ACP plain-language thread (не для CI): +Ручний smoke plain-language thread для ACP (не для CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Зберігайте цей скрипт для workflows регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації thread ACP, тому не видаляйте його. +- Зберігайте цей скрипт для робочих процесів регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації thread в ACP, тож не видаляйте його. -Корисні env vars: +Корисні 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 vars, отриманих із `OPENCLAW_PROFILE_FILE`, із тимчасовими каталогами config/workspace і без зовнішніх монтувань CLI auth -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI всередині Docker -- Зовнішні каталоги/файли CLI auth під `$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_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) монтується в `/home/node/.profile` і зчитується перед запуском тестів +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевіряти лише env-змінні, зчитані з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги config/workspace і без монтування auth зовнішнього CLI +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI усередині Docker +- Зовнішні каталоги/файли auth CLI під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед стартом тестів + - Типові каталоги: `.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 + - Для ручного перевизначення використовуйте `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`, щоб гарантувати, що облікові дані надходять зі сховища профілю (а не з env) +- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку gateway надає для smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити nonce-check prompt, який використовує smoke Open WebUI +- `OPENWEBUI_IMAGE=...`, щоб перевизначити закріплений тег image Open WebUI ## Перевірка коректності документації -Після редагування документації запускайте перевірки документації: `pnpm check:docs`. +Запускайте перевірки docs після редагування документації: `pnpm check:docs`. Запускайте повну перевірку anchor у Mintlify, коли вам також потрібні перевірки заголовків у межах сторінки: `pnpm docs:check-links:anchors`. -## Офлайн-регресія (безпечно для CI) +## Офлайн-регресії (безпечні для CI) Це регресії «реального pipeline» без реальних провайдерів: -- Виклик tools 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): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") +- Виклик інструментів 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") -## Оцінювання надійності агента (Skills) +## Оцінювання надійності агентів (Skills) -У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агента»: +У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агентів»: -- Mock tool-calling через реальний цикл gateway + agent (`src/gateway/gateway.test.ts`). -- Наскрізні потоки майстра, які перевіряють session wiring і ефекти конфігурації (`src/gateway/gateway.test.ts`). +- Mock-виклик інструментів через реальний gateway + цикл агента (`src/gateway/gateway.test.ts`). +- Наскрізні потоки майстра, які перевіряють wiring сесії та ефекти config (`src/gateway/gateway.test.ts`). -Чого ще бракує для Skills (див. [Skills](/uk/tools/skills)): +Чого все ще бракує для Skills (див. [Skills](/uk/tools/skills)): -- **Прийняття рішень:** коли Skills перелічені в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)? -- **Виконання вимог:** чи читає агент `SKILL.md` перед використанням і чи дотримується необхідних кроків/аргументів? -- **Контракти workflow:** багатокрокові сценарії, які перевіряють порядок tools, перенесення history сесії та межі sandbox. +- **Прийняття рішень:** коли в prompt перелічено Skills, чи вибирає агент правильний Skill (або уникає нерелевантних)? +- **Відповідність вимогам:** чи читає агент `SKILL.md` перед використанням і чи виконує обов’язкові кроки/аргументи? +- **Контракти workflow:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. -Майбутні оцінювання мають спочатку залишатися детермінованими: +Майбутні eval слід насамперед залишати детермінованими: -- Runner сценаріїв, який використовує mock-провайдерів для перевірки викликів tools + їх порядку, читання skill-файлів і wiring сесії. +- Runner сценаріїв із mock-провайдерами для перевірки викликів інструментів + їх порядку, читання skill-файлів і wiring сесії. - Невеликий набір сценаріїв, зосереджених на Skills (використовувати чи уникати, gating, prompt injection). -- Необов’язкові live-оцінювання (лише за явним увімкненням, із gating через env) тільки після того, як буде готовий безпечний для CI набір. +- Необов’язкові live eval (opt-in, керовані через env) — лише після того, як буде готовий безпечний для CI набір. -## Contract-тести (форма Plugin і channel) +## Контрактні тести (форма Plugin і channel) -Contract-тести перевіряють, що кожен зареєстрований Plugin і channel відповідає своєму -контракту інтерфейсу. Вони проходять по всіх виявлених plugins і запускають набір -перевірок форми та поведінки. Типовий unit lane `pnpm test` навмисно -пропускає ці спільні seam- і smoke-файли; запускайте contract-команди явно, -коли зачіпаєте спільні поверхні channel або provider. +Контрактні тести перевіряють, що кожен зареєстрований Plugin і channel відповідає своєму +контракту інтерфейсу. Вони ітеруються по всіх виявлених plugin і запускають набір +перевірок форми та поведінки. Типовий unit-lane `pnpm test` навмисно +пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, +коли змінюєте спільні поверхні channel або провайдера. ### Команди - Усі контракти: `pnpm test:contracts` - Лише контракти channel: `pnpm test:contracts:channels` -- Лише контракти provider: `pnpm test:contracts:plugins` +- Лише контракти провайдерів: `pnpm test:contracts:plugins` ### Контракти channel Розташовані в `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** - Обробка ID тредів -- **directory** - API каталогу/ростера -- **group-policy** - Забезпечення групових політик +- **threading** - Обробка ID thread +- **directory** - API directory/roster +- **group-policy** - Застосування group policy -### Контракти статусу provider +### Контракти статусу провайдера Розташовані в `src/plugins/contracts/*.contract.test.ts`. - **status** - Перевірки статусу channel - **registry** - Форма реєстру Plugin -### Контракти provider +### Контракти провайдерів Розташовані в `src/plugins/contracts/*.contract.test.ts`: @@ -689,32 +691,32 @@ Contract-тести перевіряють, що кожен зареєстров - **catalog** - API каталогу моделей - **discovery** - Виявлення Plugin - **loader** - Завантаження Plugin -- **runtime** - Runtime provider +- **runtime** - Runtime провайдера - **shape** - Форма/інтерфейс Plugin - **wizard** - Майстер налаштування ### Коли запускати -- Після зміни експортів або subpaths plugin-sdk -- Після додавання або зміни channel чи provider Plugin -- Після рефакторингу реєстрації Plugin або виявлення +- Після зміни експортів або subpath у plugin-sdk +- Після додавання або зміни channel чи plugin провайдера +- Після рефакторингу реєстрації plugin або виявлення -Contract-тести запускаються в CI і не потребують реальних API-ключів. +Контрактні тести запускаються в CI і не потребують реальних API-ключів. -## Додавання регресійних тестів (рекомендації) +## Додавання регресій (настанови) -Коли ви виправляєте проблему provider/model, виявлену в live: +Коли ви виправляєте проблему провайдера/моделі, виявлену в live: -- Додайте безпечну для CI регресію, якщо це можливо (mock/stub provider або фіксація точної трансформації форми запиту) -- Якщо проблема за своєю природою лише для live (rate limits, політики auth), залишайте live-тест вузьким і таким, що вмикається через env vars -- Віддавайте перевагу найменшому рівню, який виявляє баг: - - баг конвертації/відтворення запиту provider → прямий тест моделей - - баг session/history/tool pipeline Gateway → live smoke Gateway або безпечний для CI mock-тест Gateway -- Guardrail для обходу SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль для кожного класу SecretRef з metadata реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id із сегментами обходу відхиляються. - - Якщо ви додаєте нове сімейство цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно завершується невдало для некласифікованих target id, щоб нові класи не можна було тихо пропустити. +- Додайте безпечну для CI регресію, якщо це можливо (mock/stub провайдера або фіксація точної трансформації форми запиту) +- Якщо проблема за своєю природою лише live (rate limit, політики auth), залишайте live-тест вузьким і opt-in через env-змінні +- Віддавайте перевагу найменшому шару, який виявляє помилку: + - помилка конвертації/відтворення запиту провайдера → тест прямих моделей + - помилка в pipeline сесії/історії/інструментів gateway → live smoke Gateway або безпечний для CI mock-тест gateway +- Guardrail обходу 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, щоб нові класи не могли бути тихо пропущені. -## Пов’язані матеріали +## Пов’язане -- [Live-тестування](/uk/help/testing-live) +- [Тестування live](/uk/help/testing-live) - [CI](/uk/ci) diff --git a/docs/uk/plugins/google-meet.md b/docs/uk/plugins/google-meet.md index f343a3832..ee3c71495 100644 --- a/docs/uk/plugins/google-meet.md +++ b/docs/uk/plugins/google-meet.md @@ -2,13 +2,13 @@ read_when: - Ви хочете, щоб агент OpenClaw приєднався до виклику Google Meet - Ви налаштовуєте Chrome, вузол Chrome або Twilio як транспорт Google Meet -summary: 'Plugin Google Meet: приєднання до явних URL-адрес Meet через Chrome або Twilio з типовими налаштуваннями голосу в реальному часі' +summary: 'Plugin Google Meet: приєднання до явних URL-адрес Meet через Chrome або Twilio з типовими параметрами голосового зв’язку в реальному часі' title: Plugin Google Meet x-i18n: - generated_at: "2026-04-24T15:23:00Z" + generated_at: "2026-04-24T16:12:19Z" model: gpt-5.4 provider: openai - source_hash: 920ed629e7089dd6576ca8aec31f48425b3abb3bf62ef90b00bb48bf72ef4262 + source_hash: f96c5a1e08155514155094602e4d32c232cfa7f47f4105fd9b75a57cbd2d6535 source_path: plugins/google-meet.md workflow: 15 --- @@ -19,19 +19,19 @@ x-i18n: Plugin є навмисно явним: -- Він приєднується лише за явним URL `https://meet.google.com/...`. -- Голос `realtime` є типовим режимом. -- Голос у режимі реального часу може повертатися до повного агента OpenClaw, коли потрібні глибші міркування або інструменти. -- Автентифікація починається як особистий Google OAuth або вже виконаний вхід у профіль Chrome. +- Він приєднується лише за явною URL-адресою `https://meet.google.com/...`. +- Голосовий зв’язок `realtime` є типовим режимом. +- Голосовий зв’язок у реальному часі може повертатися до повного агента OpenClaw, коли потрібні глибші міркування або інструменти. +- Автентифікація починається як персональний Google OAuth або вже виконаний вхід у профіль Chrome. - Автоматичного оголошення згоди немає. -- Типовий аудіобекенд Chrome — `BlackHole 2ch`. -- Chrome може працювати локально або на підключеному вузлі Node. -- Twilio приймає номер для дозвону та необов’язковий PIN або послідовність DTMF. +- Типовим аудіобекендом Chrome є `BlackHole 2ch`. +- Chrome може працювати локально або на спареному вузлі-хості. +- Twilio приймає номер для дозвону плюс необов’язковий PIN або послідовність DTMF. - Команда CLI — `googlemeet`; `meet` зарезервовано для ширших робочих процесів агентських телеконференцій. ## Швидкий старт -Установіть локальні аудіозалежності та налаштуйте голосового провайдера бекенда в реальному часі. OpenAI використовується типово; Google Gemini Live також працює з `realtime.provider: "google"`: +Установіть локальні аудіозалежності та налаштуйте бекенд-провайдера голосового зв’язку в реальному часі. OpenAI використовується за замовчуванням; Google Gemini Live також працює з `realtime.provider: "google"`: ```bash brew install blackhole-2ch sox @@ -40,13 +40,13 @@ export OPENAI_API_KEY=sk-... export GEMINI_API_KEY=... ``` -`blackhole-2ch` установлює віртуальний аудіопристрій `BlackHole 2ch`. Інсталятор Homebrew вимагає перезавантаження, перш ніж macOS зробить пристрій доступним: +`blackhole-2ch` установлює віртуальний аудіопристрій `BlackHole 2ch`. Інсталятор Homebrew потребує перезавантаження, перш ніж macOS зробить пристрій доступним: ```bash sudo reboot ``` -Після перезавантаження перевірте обидві частини: +Після перезавантаження перевірте обидві складові: ```bash system_profiler SPAudioDataType | grep -i BlackHole @@ -89,16 +89,16 @@ openclaw googlemeet join https://meet.google.com/abc-defg-hij } ``` -Chrome приєднується як профіль Chrome, у якому виконано вхід. У Meet виберіть `BlackHole 2ch` для шляху мікрофона/динаміка, який використовує OpenClaw. Для чистого дуплексного аудіо використовуйте окремі віртуальні пристрої або граф на зразок Loopback; одного пристрою BlackHole достатньо для першого smoke test, але може виникати луна. +Chrome приєднується як профіль Chrome, у якому вже виконано вхід. У Meet виберіть `BlackHole 2ch` для шляху мікрофона/динаміка, який використовує OpenClaw. Для чистого дуплексного аудіо використовуйте окремі віртуальні пристрої або граф у стилі Loopback; одного пристрою BlackHole достатньо для першого швидкого тесту, але він може створювати відлуння. ### Локальний Gateway + Parallels Chrome -Вам **не** потрібен повний OpenClaw Gateway або ключ API моделі всередині macOS VM лише для того, щоб Chrome належав VM. Запустіть Gateway і агента локально, а потім запустіть хост вузла в VM. Один раз увімкніть укомплектований Plugin у VM, щоб вузол оголосив команду Chrome: +Вам **не** потрібен повний OpenClaw Gateway або ключ API моделі всередині macOS VM лише для того, щоб Chrome працював у VM. Запустіть Gateway і агента локально, а потім запустіть хост вузла у VM. Увімкніть вбудований Plugin у VM один раз, щоб вузол анонсував команду Chrome: -Що де працює: +Що де запускається: -- Хост Gateway: OpenClaw Gateway, робочий простір агента, ключі моделі/API, провайдер реального часу та конфігурація Plugin Google Meet. -- Parallels macOS VM: OpenClaw CLI/хост вузла, Google Chrome, SoX, BlackHole 2ch і профіль Chrome із входом у Google. +- Хост Gateway: OpenClaw Gateway, робочий простір агента, ключі моделі/API, провайдер realtime та конфігурація Plugin Google Meet. +- macOS VM у Parallels: CLI/node host OpenClaw, Google Chrome, SoX, BlackHole 2ch і профіль Chrome з виконаним входом у Google. - Не потрібно у VM: служба Gateway, конфігурація агента, ключ OpenAI/GPT або налаштування провайдера моделі. Установіть залежності у VM: @@ -120,7 +120,7 @@ system_profiler SPAudioDataType | grep -i BlackHole command -v rec play ``` -Установіть або оновіть OpenClaw у VM, а потім увімкніть там укомплектований Plugin: +Установіть або оновіть OpenClaw у VM, а потім увімкніть там вбудований Plugin: ```bash openclaw plugins enable google-meet @@ -132,7 +132,7 @@ openclaw plugins enable google-meet openclaw node run --host --port 18789 --display-name parallels-macos ``` -Якщо `` — це LAN IP і ви не використовуєте TLS, вузол відхилить відкритий WebSocket, якщо ви явно не дозволите це для цієї довіреної приватної мережі: +Якщо `` — це LAN IP і ви не використовуєте TLS, вузол відхиляє plaintext WebSocket, якщо ви явно не дозволите це для цієї довіреної приватної мережі: ```bash OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 \ @@ -156,7 +156,7 @@ openclaw devices list openclaw devices approve ``` -Підтвердьте, що Gateway бачить вузол і що він оголошує `googlemeet.chrome`: +Підтвердьте, що Gateway бачить вузол і що він анонсує як `googlemeet.chrome`, так і можливість браузера/`browser.proxy`: ```bash openclaw nodes status @@ -168,7 +168,7 @@ openclaw nodes status { gateway: { nodes: { - allowCommands: ["googlemeet.chrome"], + allowCommands: ["googlemeet.chrome", "browser.proxy"], }, }, plugins: { @@ -200,47 +200,47 @@ openclaw googlemeet join https://meet.google.com/abc-defg-hij або попросіть агента використати інструмент `google_meet` із `transport: "chrome-node"`. -Для smoke test однією командою, який створює або повторно використовує сеанс, промовляє відому фразу та виводить стан сеансу: +Для швидкого тесту однією командою, який створює або повторно використовує сеанс, промовляє відому фразу та виводить стан сеансу: ```bash openclaw googlemeet test-speech https://meet.google.com/abc-defg-hij ``` -Якщо `chromeNode.node` не вказано, OpenClaw виконує автовибір лише тоді, коли рівно один підключений вузол оголошує `googlemeet.chrome`. Якщо підключено кілька придатних вузлів, установіть `chromeNode.node` на id вузла, відображуване ім’я або віддалену IP-адресу. +Якщо `chromeNode.node` пропущено, OpenClaw автоматично вибирає вузол лише тоді, коли рівно один підключений вузол анонсує і `googlemeet.chrome`, і керування браузером. Якщо підключено кілька придатних вузлів, установіть `chromeNode.node` як id вузла, відображуване ім’я або віддалену IP-адресу. Поширені перевірки збоїв: -- `No connected Google Meet-capable node`: запустіть `openclaw node run` у VM, схваліть сполучення та переконайтеся, що у VM було виконано `openclaw plugins enable google-meet`. Також підтвердьте, що хост Gateway дозволяє команду вузла через `gateway.nodes.allowCommands: ["googlemeet.chrome"]`. +- `No connected Google Meet-capable node`: запустіть `openclaw node run` у VM, схваліть спарювання та переконайтеся, що у VM були виконані `openclaw plugins enable google-meet` і `openclaw plugins enable browser`. Також підтвердьте, що хост Gateway дозволяє обидві команди вузла через `gateway.nodes.allowCommands: ["googlemeet.chrome", "browser.proxy"]`. - `BlackHole 2ch audio device not found on the node`: установіть `blackhole-2ch` у VM і перезавантажте VM. -- Chrome відкривається, але не може приєднатися: увійдіть у Chrome всередині VM або залиште `chrome.guestName` встановленим для гостьового входу. Автоприєднання гостя використовує Chrome Apple Events; якщо воно повідомляє про попередження автоматизації, увімкніть Chrome > View > Developer > Allow JavaScript from Apple Events, а потім повторіть спробу. -- Дубльовані вкладки Meet: залиште `chrome.reuseExistingTab: true` увімкненим. OpenClaw активує наявну вкладку для того самого URL Meet перед відкриттям нової. -- Немає аудіо: у Meet спрямуйте мікрофон/динамік через шлях віртуального аудіопристрою, який використовує OpenClaw; використовуйте окремі віртуальні пристрої або маршрутизацію на зразок Loopback для чистого дуплексного аудіо. +- Chrome відкривається, але не може приєднатися: увійдіть у профіль браузера всередині VM або залиште `chrome.guestName` установленим для гостьового входу. Автоматичне гостьове приєднання використовує автоматизацію браузера OpenClaw через browser proxy вузла; переконайтеся, що конфігурація browser вузла вказує на потрібний профіль, наприклад `browser.defaultProfile: "user"` або профіль named existing-session. +- Дубльовані вкладки Meet: залиште `chrome.reuseExistingTab: true` увімкненим. OpenClaw активує наявну вкладку для тієї самої URL-адреси Meet перед відкриттям нової. +- Немає аудіо: у Meet спрямовуйте аудіо мікрофона й динаміка через шлях віртуального аудіопристрою, який використовує OpenClaw; використовуйте окремі віртуальні пристрої або маршрутизацію в стилі Loopback для чистого дуплексу. ## Примітки щодо встановлення -Типове налаштування реального часу для Chrome використовує два зовнішні інструменти: +Типове налаштування realtime для Chrome використовує два зовнішні інструменти: -- `sox`: утиліта командного рядка для аудіо. Plugin використовує її команди `rec` і `play` для типового аудіомоста G.711 mu-law 8 кГц. -- `blackhole-2ch`: віртуальний аудіодрайвер macOS. Він створює аудіопристрій `BlackHole 2ch`, через який Chrome/Meet можуть маршрутизувати звук. +- `sox`: утиліта аудіо командного рядка. Plugin використовує її команди `rec` і `play` для типового аудіомоста G.711 mu-law 8 кГц. +- `blackhole-2ch`: віртуальний аудіодрайвер macOS. Він створює аудіопристрій `BlackHole 2ch`, через який Chrome/Meet може маршрутизувати звук. -OpenClaw не комплектує та не розповсюджує жоден із цих пакетів. У документації користувачам пропонується встановити їх як залежності хоста через Homebrew. SoX ліцензовано як `LGPL-2.0-only AND GPL-2.0-only`; BlackHole — за GPL-3.0. Якщо ви створюєте інсталятор або appliance, який комплектує BlackHole разом з OpenClaw, перегляньте умови вихідної ліцензії BlackHole або отримайте окрему ліцензію від Existential Audio. +OpenClaw не постачається разом із жодним із цих пакетів і не розповсюджує їх. У документації користувачам пропонується встановлювати їх як залежності хоста через Homebrew. SoX ліцензовано як `LGPL-2.0-only AND GPL-2.0-only`; BlackHole — за GPL-3.0. Якщо ви створюєте інсталятор або appliance, що містить BlackHole разом з OpenClaw, перегляньте умови ліцензування BlackHole в апстрімі або отримайте окрему ліцензію від Existential Audio. ## Транспорти ### Chrome -Транспорт Chrome відкриває URL Meet у Google Chrome і приєднується як профіль Chrome, у якому виконано вхід. На macOS Plugin перед запуском перевіряє наявність `BlackHole 2ch`. Якщо налаштовано, він також запускає команду перевірки стану аудіомоста та команду запуску перед відкриттям Chrome. Використовуйте `chrome`, коли Chrome/аудіо працюють на хості Gateway; використовуйте `chrome-node`, коли Chrome/аудіо працюють на підключеному вузлі, наприклад у Parallels macOS VM. +Транспорт Chrome відкриває URL-адресу Meet у Google Chrome і приєднується як профіль Chrome, у якому виконано вхід. На macOS Plugin перед запуском перевіряє наявність `BlackHole 2ch`. Якщо налаштовано, він також запускає команду перевірки стану аудіомоста та команду запуску перед відкриттям Chrome. Використовуйте `chrome`, коли Chrome/аудіо працюють на хості Gateway; використовуйте `chrome-node`, коли Chrome/аудіо працюють на спареному вузлі, наприклад у macOS VM Parallels. ```bash openclaw googlemeet join https://meet.google.com/abc-defg-hij --transport chrome openclaw googlemeet join https://meet.google.com/abc-defg-hij --transport chrome-node ``` -Спрямуйте аудіо мікрофона та динаміка Chrome через локальний аудіоміст OpenClaw. Якщо `BlackHole 2ch` не встановлено, приєднання завершиться помилкою налаштування, а не тихим підключенням без аудіошляху. +Спрямуйте аудіо мікрофона та динаміка Chrome через локальний аудіоміст OpenClaw. Якщо `BlackHole 2ch` не встановлено, приєднання завершується помилкою налаштування, а не тихим приєднанням без аудіошляху. ### Twilio -Транспорт Twilio — це строгий план набору, делегований Plugin Voice Call. Він не аналізує сторінки Meet для пошуку телефонних номерів. +Транспорт Twilio — це суворий план набору, делегований Plugin Voice Call. Він не аналізує сторінки Meet для пошуку номерів телефону. ```bash openclaw googlemeet join https://meet.google.com/abc-defg-hij \ @@ -260,13 +260,13 @@ openclaw googlemeet join https://meet.google.com/abc-defg-hij \ ## OAuth і попередня перевірка -Доступ до Google Meet Media API спочатку використовує особистий OAuth-клієнт. Налаштуйте `oauth.clientId` і, за потреби, `oauth.clientSecret`, а потім виконайте: +Доступ до Google Meet Media API спочатку використовує персональний клієнт OAuth. Налаштуйте `oauth.clientId` і за потреби `oauth.clientSecret`, а потім виконайте: ```bash openclaw googlemeet auth login --json ``` -Команда виводить блок конфігурації `oauth` із refresh token. Вона використовує PKCE, localhost callback на `http://localhost:8085/oauth2callback` і ручний потік копіювання/вставлення з `--manual`. +Команда виводить блок конфігурації `oauth` з токеном оновлення. Вона використовує PKCE, localhost callback на `http://localhost:8085/oauth2callback` і ручний потік копіювання/вставлення з `--manual`. Ці змінні середовища приймаються як резервні варіанти: @@ -274,27 +274,28 @@ openclaw googlemeet auth login --json - `OPENCLAW_GOOGLE_MEET_CLIENT_SECRET` або `GOOGLE_MEET_CLIENT_SECRET` - `OPENCLAW_GOOGLE_MEET_REFRESH_TOKEN` або `GOOGLE_MEET_REFRESH_TOKEN` - `OPENCLAW_GOOGLE_MEET_ACCESS_TOKEN` або `GOOGLE_MEET_ACCESS_TOKEN` -- `OPENCLAW_GOOGLE_MEET_ACCESS_TOKEN_EXPIRES_AT` або `GOOGLE_MEET_ACCESS_TOKEN_EXPIRES_AT` +- `OPENCLAW_GOOGLE_MEET_ACCESS_TOKEN_EXPIRES_AT` або + `GOOGLE_MEET_ACCESS_TOKEN_EXPIRES_AT` - `OPENCLAW_GOOGLE_MEET_DEFAULT_MEETING` або `GOOGLE_MEET_DEFAULT_MEETING` - `OPENCLAW_GOOGLE_MEET_PREVIEW_ACK` або `GOOGLE_MEET_PREVIEW_ACK` -Визначте Meet URL, код або `spaces/{id}` через `spaces.get`: +Розв’яжіть URL-адресу Meet, код або `spaces/{id}` через `spaces.get`: ```bash openclaw googlemeet resolve-space --meeting https://meet.google.com/abc-defg-hij ``` -Запустіть попередню перевірку перед роботою з медіа: +Запускайте попередню перевірку перед роботою з медіа: ```bash openclaw googlemeet preflight --meeting https://meet.google.com/abc-defg-hij ``` -Установлюйте `preview.enrollmentAcknowledged: true` лише після підтвердження, що ваш Cloud project, OAuth principal і учасники зустрічі зареєстровані в Google Workspace Developer Preview Program для Meet media APIs. +Установлюйте `preview.enrollmentAcknowledged: true` лише після підтвердження, що ваш проєкт Cloud, принципал OAuth і учасники зустрічі зареєстровані в Google Workspace Developer Preview Program для Meet media APIs. ## Конфігурація -Для типового шляху Chrome у режимі реального часу достатньо лише ввімкненого Plugin, BlackHole, SoX і ключа голосового провайдера бекенда в реальному часі. OpenAI використовується типово; установіть `realtime.provider: "google"`, щоб використовувати Google Gemini Live: +Поширений шлях Chrome realtime потребує лише ввімкненого Plugin, BlackHole, SoX і ключа бекенд-провайдера голосового зв’язку в реальному часі. OpenAI використовується за замовчуванням; установіть `realtime.provider: "google"` для використання Google Gemini Live: ```bash brew install blackhole-2ch sox @@ -322,18 +323,18 @@ export GEMINI_API_KEY=... - `defaultTransport: "chrome"` - `defaultMode: "realtime"` -- `chromeNode.node`: необов’язкові id/ім’я/IP вузла для `chrome-node` +- `chromeNode.node`: необов’язковий id/ім’я/IP вузла для `chrome-node` - `chrome.audioBackend: "blackhole-2ch"` -- `chrome.guestName: "OpenClaw Agent"`: ім’я, яке використовується на екрані гостя Meet без входу -- `chrome.autoJoin: true`: найкраща можлива спроба заповнити ім’я гостя та натиснути Join Now -- `chrome.reuseExistingTab: true`: активувати наявну вкладку Meet замість відкриття дублікатів -- `chrome.waitForInCallMs: 20000`: очікувати, поки вкладка Meet повідомить про активний виклик, перш ніж запускати вступ у режимі реального часу +- `chrome.guestName: "OpenClaw Agent"`: ім’я, що використовується на сторінці гостьового входу Meet без авторизації +- `chrome.autoJoin: true`: заповнення гостьового імені та натискання Join Now за принципом best-effort через автоматизацію браузера OpenClaw на `chrome-node` +- `chrome.reuseExistingTab: true`: активує наявну вкладку Meet замість відкриття дублікатів +- `chrome.waitForInCallMs: 20000`: очікування, доки вкладка Meet повідомить про стан in-call, перш ніж буде ініційовано вступне повідомлення realtime - `chrome.audioInputCommand`: команда SoX `rec`, що записує аудіо G.711 mu-law 8 кГц у stdout -- `chrome.audioOutputCommand`: команда SoX `play`, що читає аудіо G.711 mu-law 8 кГц із stdin +- `chrome.audioOutputCommand`: команда SoX `play`, що зчитує аудіо G.711 mu-law 8 кГц із stdin - `realtime.provider: "openai"` - `realtime.toolPolicy: "safe-read-only"` - `realtime.instructions`: короткі усні відповіді з `openclaw_agent_consult` для глибших відповідей -- `realtime.introMessage`: коротка усна перевірка готовності, коли міст реального часу підключається; установіть `""`, щоб приєднатися беззвучно +- `realtime.introMessage`: коротка усна перевірка готовності, коли підключається міст realtime; установіть `""`, щоб приєднуватися беззвучно Необов’язкові перевизначення: @@ -353,7 +354,7 @@ export GEMINI_API_KEY=... realtime: { provider: "google", toolPolicy: "owner", - introMessage: "Скажи дослівно: Я тут.", + introMessage: "Скажи рівно так: Я тут.", providers: { google: { model: "gemini-2.5-flash-native-audio-preview-12-2025", @@ -392,68 +393,68 @@ export GEMINI_API_KEY=... } ``` -Використовуйте `transport: "chrome"`, коли Chrome працює на хості Gateway. Використовуйте `transport: "chrome-node"`, коли Chrome працює на підключеному вузлі, наприклад у Parallels VM. В обох випадках модель реального часу та `openclaw_agent_consult` працюють на хості Gateway, тому облікові дані моделі залишаються там. +Використовуйте `transport: "chrome"`, коли Chrome працює на хості Gateway. Використовуйте `transport: "chrome-node"`, коли Chrome працює на спареному вузлі, наприклад у VM Parallels. В обох випадках модель realtime і `openclaw_agent_consult` працюють на хості Gateway, тому облікові дані моделі залишаються там. -Використовуйте `action: "status"`, щоб перелічити активні сеанси або перевірити ID сеансу. Використовуйте `action: "speak"` із `sessionId` і `message`, щоб агент реального часу заговорив негайно. Використовуйте `action: "test_speech"`, щоб створити або повторно використати сеанс, запустити відому фразу та повернути стан `inCall`, якщо хост Chrome може його повідомити. Використовуйте `action: "leave"`, щоб позначити сеанс як завершений. +Використовуйте `action: "status"`, щоб отримати список активних сеансів або перевірити ідентифікатор сеансу. Використовуйте `action: "speak"` з `sessionId` і `message`, щоб агент realtime почав говорити негайно. Використовуйте `action: "test_speech"`, щоб створити або повторно використати сеанс, запустити відому фразу й повернути стан `inCall`, якщо хост Chrome може його повідомити. Використовуйте `action: "leave"`, щоб позначити сеанс як завершений. -`status` включає стан Chrome, коли він доступний: +`status` містить стан Chrome, коли він доступний: -- `inCall`: Chrome, імовірно, перебуває всередині виклику Meet -- `micMuted`: найкраща можлива оцінка стану мікрофона Meet -- `providerConnected` / `realtimeReady`: стан голосового моста реального часу +- `inCall`: схоже, що Chrome перебуває всередині виклику Meet +- `micMuted`: best-effort стан мікрофона Meet +- `providerConnected` / `realtimeReady`: стан голосового моста realtime - `lastInputAt` / `lastOutputAt`: час останнього аудіо, отриманого мостом або надісланого до нього ```json { "action": "speak", "sessionId": "meet_...", - "message": "Скажи дослівно: Я тут і слухаю." + "message": "Скажи рівно так: Я тут і слухаю." } ``` -## Консультація агента реального часу +## Консультація агента realtime -Режим реального часу Chrome оптимізовано для живого голосового циклу. Голосовий провайдер реального часу чує аудіо зустрічі та говорить через налаштований аудіоміст. Коли моделі реального часу потрібні глибші міркування, актуальна інформація або звичайні інструменти OpenClaw, вона може викликати `openclaw_agent_consult`. +Режим Chrome realtime оптимізовано для живого голосового циклу. Провайдер голосового зв’язку realtime чує аудіо зустрічі та говорить через налаштований аудіоміст. Коли моделі realtime потрібні глибші міркування, актуальна інформація або звичайні інструменти OpenClaw, вона може викликати `openclaw_agent_consult`. -Інструмент консультації запускає звичайного агента OpenClaw у фоновому режимі з контекстом нещодавньої транскрипції зустрічі й повертає стислу усну відповідь до голосового сеансу реального часу. Потім голосова модель може озвучити цю відповідь назад у зустріч. +Інструмент консультації запускає звичайного агента OpenClaw у фоновому режимі з контекстом нещодавньої стенограми зустрічі та повертає стислу усну відповідь до голосового сеансу realtime. Потім голосова модель може озвучити цю відповідь назад у зустрічі. `realtime.toolPolicy` керує запуском консультації: -- `safe-read-only`: надає доступ до інструмента консультації й обмежує звичайного агента інструментами `read`, `web_search`, `web_fetch`, `x_search`, `memory_search` і `memory_get`. -- `owner`: надає доступ до інструмента консультації та дозволяє звичайному агенту використовувати звичайну політику інструментів агента. -- `none`: не надає моделі голосу реального часу доступ до інструмента консультації. +- `safe-read-only`: надає інструмент консультації та обмежує звичайного агента інструментами `read`, `web_search`, `web_fetch`, `x_search`, `memory_search` і `memory_get`. +- `owner`: надає інструмент консультації та дозволяє звичайному агенту використовувати звичайну політику інструментів агента. +- `none`: не надає інструмент консультації моделі голосового зв’язку realtime. -Ключ сеансу консультації має область дії в межах сеансу Meet, тому наступні виклики консультації можуть повторно використовувати попередній контекст консультації під час тієї самої зустрічі. +Ключ сеансу консультації обмежено межами кожного сеансу Meet, тому повторні виклики консультації можуть повторно використовувати попередній контекст консультації протягом тієї самої зустрічі. -Щоб примусово виконати усну перевірку готовності після того, як Chrome повністю приєднається до виклику: +Щоб примусово виконати усну перевірку готовності після того, як Chrome повністю приєднався до виклику: ```bash -openclaw googlemeet speak meet_... "Say exactly: I'm here and listening." +openclaw googlemeet speak meet_... "Скажи рівно так: Я тут і слухаю." ``` -Для повного smoke test приєднання й озвучення: +Для повного швидкого тесту приєднання та озвучення: ```bash openclaw googlemeet test-speech https://meet.google.com/abc-defg-hij \ --transport chrome-node \ - --message "Say exactly: I'm here and listening." + --message "Скажи рівно так: Я тут і слухаю." ``` ## Примітки -Офіційний медіа-API Google Meet орієнтований на отримання, тому для озвучення у виклику Meet усе ще потрібен шлях учасника. Цей Plugin зберігає цю межу видимою: Chrome обробляє участь у браузері та локальну маршрутизацію аудіо; Twilio обробляє участь через телефонний дозвін. +Офіційний медіа-API Google Meet орієнтований на приймання, тому для мовлення у виклик Meet усе ще потрібен шлях учасника. Цей Plugin зберігає цю межу видимою: Chrome відповідає за участь через браузер і локальну маршрутизацію аудіо; Twilio відповідає за участь через телефонний дозвін. -Для режиму реального часу Chrome потрібно одне з такого: +Режиму Chrome realtime потрібно одне з такого: -- `chrome.audioInputCommand` плюс `chrome.audioOutputCommand`: OpenClaw керує мостом моделі реального часу та передає аудіо G.711 mu-law 8 кГц між цими командами та вибраним голосовим провайдером реального часу. -- `chrome.audioBridgeCommand`: зовнішня команда моста керує всім локальним аудіошляхом і має завершитися після запуску або перевірки свого демона. +- `chrome.audioInputCommand` плюс `chrome.audioOutputCommand`: OpenClaw керує мостом моделі realtime і передає аудіо G.711 mu-law 8 кГц між цими командами та вибраним провайдером голосового зв’язку realtime. +- `chrome.audioBridgeCommand`: зовнішня команда моста повністю керує локальним аудіошляхом і має завершитися після запуску або перевірки свого демона. -Для чистого дуплексного аудіо маршрутизуйте вихід Meet і мікрофон Meet через окремі віртуальні пристрої або граф віртуальних пристроїв на зразок Loopback. Один спільний пристрій BlackHole може повертати голоси інших учасників назад у виклик. +Для чистого дуплексного аудіо маршрутизуйте вихід Meet і мікрофон Meet через окремі віртуальні пристрої або граф віртуальних пристроїв у стилі Loopback. Один спільний пристрій BlackHole може повертати голоси інших учасників назад у виклик. -`googlemeet speak` запускає активний аудіоміст реального часу для сеансу Chrome. `googlemeet leave` зупиняє цей міст. Для сеансів Twilio, делегованих через Plugin Voice Call, `leave` також завершує базовий голосовий виклик. +`googlemeet speak` запускає активний аудіоміст realtime для сеансу Chrome. `googlemeet leave` зупиняє цей міст. Для сеансів Twilio, делегованих через Plugin Voice Call, `leave` також кладе слухавку базового голосового виклику. ## Пов’язане -- [Plugin голосових викликів](/uk/plugins/voice-call) -- [Режим розмови](/uk/nodes/talk) +- [Plugin Voice call](/uk/plugins/voice-call) +- [Режим Talk](/uk/nodes/talk) - [Створення Plugin](/uk/plugins/building-plugins)