From 7e983dc3ccfb5e9c45cc4a5f85764e501e761950 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Tue, 21 Apr 2026 18:06:15 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/ci.md | 100 ++++++++--------- docs/uk/gateway/multiple-gateways.md | 160 ++++++++++++--------------- 2 files changed, 120 insertions(+), 140 deletions(-) diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 35dc7bfdb..e2a5a2aa8 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,89 +1,89 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося + - Вам потрібно зрозуміти, чому завдання CI було або не було запущено - Ви налагоджуєте збої перевірок GitHub Actions -summary: Граф завдань CI, шлюзи області дії та локальні еквіваленти команд +summary: Граф завдань CI, шлюзи області змін і локальні еквіваленти команд title: Конвеєр CI x-i18n: - generated_at: "2026-04-21T02:32:23Z" + generated_at: "2026-04-21T18:05:48Z" model: gpt-5.4 provider: openai - source_hash: 88a98d777fd61be1603417b71779aaf42a24d602b2437ad549f0075f22494cec + source_hash: 4d01a178402976cdf7c3c864695e8a12d3f7d1d069a77ea1b02a8aef2a3497f7 source_path: ci.md workflow: 15 --- # Конвеєр CI -CI запускається при кожному push у `main` і для кожного pull request. Він використовує розумне визначення області, щоб пропускати дорогі завдання, коли змінено лише не пов’язані частини. +CI запускається для кожного push у `main` і для кожного pull request. Він використовує розумне визначення області змін, щоб пропускати дорогі завдання, коли змінено лише нерелевантні частини. ## Огляд завдань -| Завдання | Призначення | Коли запускається | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Визначає зміни лише в документації, змінені області, змінені extensions і будує маніфест CI | Завжди для push і PR без чернетки | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR без чернетки | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо рекомендацій npm | Завжди для push і PR без чернетки | -| `security-fast` | Обов’язковий агрегований результат для швидких завдань безпеки | Завжди для push і PR без чернетки | -| `build-artifacts` | Один раз збирає `dist/` і Control UI, завантажує повторно використовувані артефакти для залежних завдань | Зміни, релевантні для Node | -| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от bundled/plugin-contract/protocol перевірки | Зміни, релевантні для Node | -| `checks-fast-contracts-channels` | Розшардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | -| `checks-node-extensions` | Повні шардовані тести bundled-plugin для всього набору extensions | Зміни, релевантні для Node | -| `checks-node-core-test` | Шардовані тести core Node, без ліній каналів, bundled, контрактів і extensions | Зміни, релевантні для Node | -| `extension-fast` | Цільові тести лише для змінених bundled plugins | Коли виявлено зміни extensions | -| `check` | Розшардований еквівалент основного локального шлюзу: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | -| `check-additional` | Шарди архітектури, меж, guard-перевірок extension-surface, package-boundary і gateway-watch | Зміни, релевантні для Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke-тест пам’яті під час запуску | Зміни, релевантні для Node | -| `checks` | Решта Linux Node-ліній: тести каналів і лише для push сумісність Node 22 | Зміни, релевантні для Node | -| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено | -| `skills-python` | Ruff + pytest для Skills на Python | Зміни, релевантні для Python Skills | -| `checks-windows` | Специфічні для Windows тестові лінії | Зміни, релевантні для Windows | -| `macos-node` | Лінія тестів TypeScript на macOS з використанням спільних зібраних артефактів | Зміни, релевантні для macOS | -| `macos-swift` | Лінтинг, збірка і тести Swift для застосунку macOS | Зміни, релевантні для macOS | -| `android` | Матриця збірки й тестів Android | Зміни, релевантні для Android | +| Завдання | Призначення | Коли запускається | +| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- | +| `preflight` | Виявляє зміни лише в документації, області змін, змінені розширення та будує маніфест CI | Завжди для push і PR не в чернетці | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR не в чернетці | +| `security-dependency-audit` | Аудит production lockfile без залежностей на основі advisories npm | Завжди для push і PR не в чернетці | +| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для push і PR не в чернетці | +| `build-artifacts` | Один раз збирає `dist/` і Control UI, завантажує повторно використовувані артефакти для downstream-завдань | Зміни, релевантні для Node | +| `checks-fast-core` | Швидкі Linux-етапи перевірки коректності, як-от bundled/plugin-contract/protocol checks | Зміни, релевантні для Node | +| `checks-fast-contracts-channels` | Розшардовані перевірки контрактів каналів зі стабільним агрегованим результатом | Зміни, релевантні для Node | +| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору розширень | Зміни, релевантні для Node | +| `checks-node-core-test` | Шарди тестів core Node, за винятком каналів, bundled, контрактних і extension-етапів | Зміни, релевантні для Node | +| `extension-fast` | Цільові тести лише для змінених bundled plugins | Коли виявлено зміни в розширеннях | +| `check` | Розшардований еквівалент основного локального шлюзу: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | +| `check-additional` | Шарди архітектурних, boundary, extension-surface guards, package-boundary і gateway-watch перевірок | Зміни, релевантні для Node | +| `build-smoke` | Smoke-тести зібраного CLI і smoke-перевірка пам’яті під час запуску | Зміни, релевантні для Node | +| `checks` | Решта Linux Node-етапів: тести каналів і сумісність Node 22 лише для push | Зміни, релевантні для Node | +| `check-docs` | Форматування документації, lint і перевірка на биті посилання | Документацію змінено | +| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python Skills | +| `checks-windows` | Windows-специфічні тестові етапи | Зміни, релевантні для Windows | +| `macos-node` | Етап тестів TypeScript на macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | +| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні для macOS | +| `android` | Матриця збірки та тестів Android | Зміни, релевантні для Android | -## Порядок fail-fast +## Порядок Fail-Fast -Завдання впорядковано так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі: +Завдання впорядковано так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запускаються дорогі: -1. `preflight` вирішує, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою без очікування важчих завдань зі створення артефактів і платформних матриць. -3. `build-artifacts` виконується паралельно зі швидкими Linux-лініями, щоб залежні споживачі могли стартувати, щойно спільна збірка буде готова. -4. Після цього розгалужуються важчі платформні й runtime-лінії: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` вирішує, які етапи взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` завершуються швидко, не чекаючи важчих матричних завдань артефактів і платформ. +3. `build-artifacts` виконується паралельно зі швидкими Linux-етапами, щоб downstream-споживачі могли почати роботу, щойно спільна збірка буде готова. +4. Після цього розгалужуються важчі платформні та runtime-етапи: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покривається unit-тестами в `src/scripts/ci-changed-scope.test.ts`. -Окремий workflow `install-smoke` повторно використовує той самий скрипт області дії через власне завдання `preflight`. Він обчислює `run_install_smoke` на основі вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, пов’язаних з install, packaging і контейнерами. +Логіка області змін розміщена в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`. +Окремий workflow `install-smoke` повторно використовує той самий скрипт області змін через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, релевантних до встановлення, пакування та контейнерів. -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо архітектурних меж, ніж широка платформна область CI: зміни в core production запускають typecheck core prod плюс тести core, зміни лише в core tests запускають лише typecheck/tests для core tests, зміни в extension production запускають typecheck extension prod плюс тести extensions, а зміни лише в extension tests запускають лише typecheck/tests для extension tests. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку на extensions, оскільки extensions залежать від цих контрактів core. Невідомі зміни в root/config безпечно розширюються до всіх ліній. +Логіка локальних changed-lanes розміщена в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо архітектурних меж, ніж широка область платформ у CI: зміни core production запускають typecheck core prod плюс тести core, зміни лише в core tests запускають лише typecheck/tests для core tests, зміни extension production запускають typecheck extension prod плюс тести розширень, а зміни лише в extension tests запускають лише typecheck/tests для extension tests. Зміни в public Plugin SDK або plugin-contract розширюють перевірку до validation розширень, тому що розширення залежать від цих core-контрактів. Невідомі зміни в корені/config безпечно переводять виконання на всі етапи. -Для push матриця `checks` додає лінію `compat-node22`, яка запускається лише для push. Для pull request цю лінію пропускають, і матриця зосереджується на звичайних тестових/channel-лініях. +Для push матриця `checks` додає етап `compat-node22`, який запускається лише для push. Для pull request цей етап пропускається, і матриця залишається зосередженою на звичайних test/channel-етапах. -Найповільніші сімейства тестів Node розділено на include-file шарди, щоб кожне завдання залишалося невеликим: channel contracts розділяють покриття registry і core на вісім зважених шардів кожне, тести команд відповіді auto-reply розділяються на чотири шарди за include-pattern, а інші великі групи префіксів відповідей auto-reply — на два шарди кожна. `check-additional` також відокремлює роботу package-boundary compile/canary від runtime topology gateway/architecture. +Найповільніші сімейства тестів Node розбиті на include-file шарди, щоб кожне завдання залишалося невеликим: channel contracts розділяють покриття registry і core на вісім зважених шардів кожне, тести auto-reply reply command поділено на чотири шарди за include-pattern, а інші великі групи auto-reply reply prefix — на два шарди кожна. `check-additional` також відокремлює compile/canary-роботи package-boundary від runtime topology gateway/architecture-робіт. -GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо лише найновіший запуск для того самого ref також не завершується з помилкою. Агреговані шардовані перевірки явно вказують на цей випадок скасування, щоб його було легше відрізнити від збою тесту. +GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо лише найновіший запуск для того самого ref також не завершується з помилкою. Агреговані shard-перевірки явно вказують на цей випадок скасування, щоб його було легше відрізнити від помилки тесту. ## Runners -| Runner | Завдання | -| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `blacksmith-16vcpu-ubuntu-2404` | `preflight`, `security-scm-fast`, `security-dependency-audit`, `security-fast`, `build-artifacts`, Linux-перевірки, перевірки документації, Python Skills, `android` | -| `blacksmith-32vcpu-windows-2025` | `checks-windows` | -| `macos-latest` | `macos-node`, `macos-swift` | +| Runner | Завдання | +| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| `blacksmith-16vcpu-ubuntu-2404` | `preflight`, `security-scm-fast`, `security-dependency-audit`, `security-fast`, `build-artifacts`, Linux checks, docs checks, Python Skills, `android` | +| `blacksmith-32vcpu-windows-2025` | `checks-windows` | +| `blacksmith-12vcpu-macos-latest` | `macos-node`, `macos-swift` у `openclaw/openclaw`; для forks використовується fallback на `macos-latest` | ## Локальні еквіваленти ```bash -pnpm changed:lanes # переглянути локальний класифікатор changed-lane для origin/main...HEAD -pnpm check:changed # розумний локальний шлюз: changed typecheck/lint/tests за граничною лінією -pnpm check # швидкий локальний шлюз: production tsgo + шардований lint + паралельні швидкі guards +pnpm changed:lanes # переглянути локальний класифікатор changed-lanes для origin/main...HEAD +pnpm check:changed # розумний локальний шлюз: змінені typecheck/lint/tests за boundary-етапом +pnpm check # швидкий локальний шлюз: production tsgo + розшардований lint + паралельні швидкі guards pnpm check:test-types -pnpm check:timed # той самий шлюз із таймінгами для кожного етапу +pnpm check:timed # той самий шлюз із вимірюванням часу для кожного етапу pnpm build:strict-smoke pnpm check:architecture pnpm test:gateway:watch-regression pnpm test # тести vitest pnpm test:channels pnpm test:contracts:channels -pnpm check:docs # форматування документації + lint + перевірка битих посилань -pnpm build # зібрати dist, коли важливі лінії CI artifact/build-smoke +pnpm check:docs # форматування docs + lint + перевірка битих посилань +pnpm build # збірка dist, коли важливі етапи CI artifact/build-smoke ``` diff --git a/docs/uk/gateway/multiple-gateways.md b/docs/uk/gateway/multiple-gateways.md index 9d8d1e096..f85e49180 100644 --- a/docs/uk/gateway/multiple-gateways.md +++ b/docs/uk/gateway/multiple-gateways.md @@ -1,136 +1,116 @@ --- read_when: - - Запуск більш ніж одного Gateway на одній машині - - Для кожного Gateway потрібні ізольовані конфігурація/стан/порти -summary: Запуск кількох Gateway OpenClaw на одному хості (ізоляція, порти та профілі) + - Запуск кількох Gateway на одній машині + - Для кожного Gateway потрібні ізольовані конфігурація, стан і порти +summary: Запускайте кілька Gateway OpenClaw на одному хості (ізоляція, порти та профілі) title: Кілька Gateway x-i18n: - generated_at: "2026-04-21T17:32:11Z" + generated_at: "2026-04-21T18:05:47Z" model: gpt-5.4 provider: openai - source_hash: 8c3fcb921bc6596040e9249467964bd9dcd40ea7c16e958bb378247b0f994a7b + source_hash: 7a0bae1fbb088d1c1b7a90bb1de8f33471a19c5fbeafd8e2a0556d8eeadf8c15 source_path: gateway/multiple-gateways.md workflow: 15 --- -# Кілька Gateway (один хост) +# Кілька Gateway (на одному хості) -У більшості конфігурацій слід використовувати один Gateway, оскільки один Gateway може обробляти кілька підключень месенджерів і агентів. Якщо вам потрібна сильніша ізоляція або резервування (наприклад, аварійний бот), запускайте окремі Gateway з ізольованими профілями/портами. +У більшості конфігурацій слід використовувати один Gateway, оскільки один Gateway може обробляти кілька підключень до месенджерів і агентів. Якщо вам потрібна сильніша ізоляція або резервування (наприклад, rescue bot), запускайте окремі Gateway з ізольованими профілями/портами. -## Контрольний список ізоляції (обов’язково) +## Найкраща рекомендована конфігурація -- `OPENCLAW_CONFIG_PATH` — окремий файл конфігурації для кожного екземпляра -- `OPENCLAW_STATE_DIR` — окремі сесії, облікові дані, кеші для кожного екземпляра -- `agents.defaults.workspace` — окремий корінь робочого простору для кожного екземпляра -- `gateway.port` (або `--port`) — унікальний для кожного екземпляра -- Похідні порти (browser/canvas) не повинні перетинатися +Для більшості користувачів найпростіша конфігурація rescue bot така: -Якщо вони спільні, ви зіткнетеся з конфліктами конфігурації та портів. +- залиште основний bot на профілі за замовчуванням +- запустіть rescue bot з `--profile rescue` +- використовуйте повністю окремий Telegram bot для облікового запису rescue +- тримайте rescue bot на іншому базовому порту, наприклад `19789` -## Рекомендовано: використовуйте типовий профіль для основного, іменований профіль — для аварійного +Це зберігає ізоляцію rescue bot від основного bot, тож він може налагоджувати або застосовувати зміни конфігурації, якщо основний bot недоступний. Залишайте щонайменше 20 портів між базовими портами, щоб похідні порти browser/canvas/CDP ніколи не конфліктували. -Профілі автоматично ізолюють `OPENCLAW_STATE_DIR` + `OPENCLAW_CONFIG_PATH` і додають суфікси до назв сервісів. Для більшості конфігурацій з аварійним ботом залиште основного бота на типовому профілі, а аварійному боту призначте іменований профіль, наприклад `rescue`. +## Швидкий старт для rescue bot + +Використовуйте це як типовий шлях, якщо у вас немає вагомої причини робити інакше: ```bash -# main (default profile) -openclaw setup -openclaw gateway --port 18789 - -# rescue -openclaw --profile rescue setup -openclaw --profile rescue gateway --port 19001 -``` - -Сервіси: - -```bash -openclaw gateway install -openclaw --profile rescue gateway install -``` - -Якщо ви хочете, щоб обидва Gateway використовували іменовані профілі, це теж працює, але не є обов’язковим. - -## Посібник для аварійного бота - -Рекомендована конфігурація: - -- залиште основного бота на типовому профілі -- запускайте аварійного бота з `--profile rescue` -- використовуйте повністю окремого Telegram-бота для аварійного облікового запису -- тримайте аварійного бота на іншому базовому порту, наприклад `19001` - -Це ізолює аварійного бота від основного, щоб він міг налагоджувати або застосовувати зміни конфігурації, якщо основний бот недоступний. Залишайте щонайменше 20 портів між базовими портами, щоб похідні порти browser/canvas/CDP ніколи не конфліктували. - -### Рекомендований канал/обліковий запис для аварійного доступу - -Для більшості конфігурацій використовуйте повністю окремого Telegram-бота для профілю аварійного доступу. - -Чому Telegram: - -- легко обмежити доступ лише для операторів -- окремий токен і ідентичність бота -- незалежність від каналу/встановлення застосунку основного бота -- простий шлях відновлення через DM, коли основний бот зламаний - -Важлива саме повна незалежність: окремий обліковий запис бота, окремі -облікові дані, окремий профіль OpenClaw, окремий робочий простір і окремий порт. - -### Рекомендований процес встановлення - -Використовуйте це як типову конфігурацію, якщо у вас немає вагомої причини робити інакше: - -```bash -# Main bot (default profile, port 18789) -openclaw onboard -openclaw gateway install - -# Rescue bot (separate Telegram bot, separate profile, port 19001) +# Rescue bot (окремий Telegram bot, окремий профіль, порт 19789) openclaw --profile rescue onboard -openclaw --profile rescue gateway install +openclaw --profile rescue gateway install --port 19789 ``` +Якщо ваш основний bot уже працює, зазвичай цього достатньо. + Під час `openclaw --profile rescue onboard`: -- використовуйте окремий токен Telegram-бота -- залишайте профіль `rescue` -- використовуйте базовий порт щонайменше на 20 вищий за порт основного бота -- прийміть типовий робочий простір аварійного бота, якщо ви вже не керуєте власним +- використовуйте окремий токен Telegram bot +- залиште профіль `rescue` +- використовуйте базовий порт щонайменше на 20 вищий, ніж у основного bot +- прийміть робочий простір rescue за замовчуванням, якщо ви вже не керуєте власним -Якщо онбординг уже встановив для вас аварійний сервіс, фінальний +Якщо onboarding уже встановив для вас службу rescue, фінальний `gateway install` не потрібен. -### Що змінює онбординг +## Чому це працює -`openclaw --profile rescue onboard` використовує звичайний процес онбордингу, але +Rescue bot залишається незалежним, оскільки має власні: + +- профіль/конфігурацію +- каталог стану +- робочий простір +- базовий порт (і похідні порти) +- токен Telegram bot + +Для більшості конфігурацій використовуйте повністю окремий Telegram bot для профілю rescue: + +- його легко залишити лише для операторів +- окремий токен bot і окрема ідентичність +- незалежність від установлення каналу/застосунку основного bot +- простий шлях відновлення через DM, коли основний bot зламаний + +## Що змінює `--profile rescue onboard` + +`openclaw --profile rescue onboard` використовує звичайний процес onboarding, але записує все в окремий профіль. -На практиці це означає, що аварійний бот отримує власні: +На практиці це означає, що rescue bot отримує власні: - файл конфігурації - каталог стану - робочий простір (типово `~/.openclaw/workspace-rescue`) -- ім’я керованого сервісу +- ім’я керованої служби -В іншому запити такі самі, як і під час звичайного онбордингу. +В іншому запити такі самі, як і під час звичайного onboarding. + +## Контрольний список ізоляції + +Зберігайте унікальність цих параметрів для кожного екземпляра Gateway: + +- `OPENCLAW_CONFIG_PATH` — окремий файл конфігурації для кожного екземпляра +- `OPENCLAW_STATE_DIR` — окремі сеанси, облікові дані, кеші для кожного екземпляра +- `agents.defaults.workspace` — окремий корінь робочого простору для кожного екземпляра +- `gateway.port` (або `--port`) — унікальний для кожного екземпляра +- похідні порти browser/canvas/CDP + +Якщо вони спільні, ви зіткнетеся з гонками конфігурації та конфліктами портів. ## Відображення портів (похідні) Базовий порт = `gateway.port` (або `OPENCLAW_GATEWAY_PORT` / `--port`). -- порт сервісу керування browser = базовий + 2 (лише loopback) +- порт служби керування browser = базовий + 2 (лише local loopback) - canvas host обслуговується на HTTP-сервері Gateway (той самий порт, що й `gateway.port`) -- порти CDP профілю Browser автоматично виділяються з діапазону `browser.controlPort + 9 .. + 108` +- порти CDP профілю browser автоматично виділяються з діапазону `browser.controlPort + 9 .. + 108` -Якщо ви перевизначаєте будь-який із них у конфігурації або env, ви повинні зберігати їх унікальними для кожного екземпляра. +Якщо ви перевизначаєте будь-що з цього в конфігурації або env, ви повинні зберегти унікальність для кожного екземпляра. -## Нотатки щодо Browser/CDP (поширена пастка) +## Нотатки про browser/CDP (типова пастка) -- **Не** фіксуйте `browser.cdpUrl` на однакові значення для кількох екземплярів. +- **Не** фіксуйте `browser.cdpUrl` на однакові значення в кількох екземплярах. - Кожному екземпляру потрібен власний порт керування browser і власний діапазон CDP (похідний від його порту gateway). -- Якщо вам потрібні явні порти CDP, задайте `browser.profiles..cdpPort` для кожного екземпляра. +- Якщо вам потрібні явні порти CDP, задавайте `browser.profiles..cdpPort` для кожного екземпляра. - Віддалений Chrome: використовуйте `browser.profiles..cdpUrl` (для кожного профілю, для кожного екземпляра). -## Приклад ручного env +## Приклад manual env ```bash OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \ @@ -139,7 +119,7 @@ openclaw gateway --port 18789 OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \ OPENCLAW_STATE_DIR=~/.openclaw-rescue \ -openclaw gateway --port 19001 +openclaw gateway --port 19789 ``` ## Швидкі перевірки @@ -155,5 +135,5 @@ openclaw --profile rescue browser status Тлумачення: -- `gateway status --deep` допомагає виявити застарілі сервіси launchd/systemd/schtasks зі старіших встановлень. -- Попереджувальний текст `gateway probe`, наприклад `multiple reachable gateways detected`, очікуваний лише тоді, коли ви навмисно запускаєте більше ніж один ізольований gateway. +- `gateway status --deep` допомагає виявити застарілі служби launchd/systemd/schtasks від старіших установлень. +- Попереджувальний текст `gateway probe`, наприклад `multiple reachable gateways detected`, є очікуваним лише тоді, коли ви навмисно запускаєте більше ніж один ізольований gateway.