From ddecb2d7be371928fac4584003fc8cc422d39499 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Sun, 3 May 2026 23:55:47 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/channels/pairing.md | 147 ++++++++++++++------------- docs/uk/concepts/progress-drafts.md | 151 ++++++++++++++-------------- docs/uk/gateway/operator-scopes.md | 84 ++++++++-------- 3 files changed, 196 insertions(+), 186 deletions(-) diff --git a/docs/uk/channels/pairing.md b/docs/uk/channels/pairing.md index c82423355..5b0fbb6da 100644 --- a/docs/uk/channels/pairing.md +++ b/docs/uk/channels/pairing.md @@ -3,61 +3,61 @@ read_when: - Налаштування контролю доступу до особистих повідомлень - Сполучення нового iOS/Android Node - Огляд стану безпеки OpenClaw -summary: 'Огляд сполучення: схвалюйте, хто може надсилати вам особисті повідомлення + які вузли можуть приєднуватися' +summary: 'Огляд сполучення: схваліть, хто може писати вам у приватні повідомлення + які вузли можуть приєднуватися' title: Сполучення x-i18n: - generated_at: "2026-05-01T23:10:05Z" + generated_at: "2026-05-03T23:54:54Z" model: gpt-5.5 provider: openai - source_hash: bb68d87c0e1dfe7c9a6a6d9415f4c63625755fb43a2e22a1d1374ff0a63e49c4 + source_hash: 4fb27840f7c9ef55e7270cc29f813e6db90b240aa2180f30952eb9485f0f8874 source_path: channels/pairing.md workflow: 16 --- -«Сполучення» — це явний крок затвердження доступу в OpenClaw. -Воно використовується у двох місцях: +«Створення пари» — це явний крок схвалення доступу в OpenClaw. +Він використовується у двох місцях: -1. **Сполучення DM** (кому дозволено говорити з ботом) -2. **Сполучення Node** (яким пристроям/вузлам дозволено приєднуватися до мережі Gateway) +1. **Створення пари для DM** (кому дозволено спілкуватися з ботом) +2. **Створення пари з Node** (яким пристроям/Node дозволено приєднуватися до мережі Gateway) Контекст безпеки: [Безпека](/uk/gateway/security) -## 1) Сполучення DM (вхідний доступ до чату) +## 1) Створення пари для DM (вхідний доступ до чату) -Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви його не затвердите. +Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви не схвалите доступ. -Типові політики DM задокументовано тут: [Безпека](/uk/gateway/security) +Стандартні політики DM задокументовано тут: [Безпека](/uk/gateway/security) -`dmPolicy: "open"` є публічним лише тоді, коли ефективний список дозволених DM містить `"*"`. -Налаштування й перевірка вимагають цей wildcard для публічно відкритих конфігурацій. Якщо наявний -стан містить `open` з конкретними записами `allowFrom`, runtime усе одно допускає -лише цих відправників, а затвердження у сховищі сполучень не розширюють доступ `open`. +`dmPolicy: "open"` є публічною лише тоді, коли ефективний список дозволених DM містить `"*"`. +Налаштування й перевірка потребують цього wildcard для публічних відкритих конфігурацій. Якщо наявний +стан містить `open` із конкретними записами `allowFrom`, середовище виконання все одно допускає +лише цих відправників, а схвалення зі сховища створення пар не розширюють доступ `open`. -Коди сполучення: +Коди створення пари: - 8 символів, великі літери, без неоднозначних символів (`0O1I`). -- **Спливають через 1 годину**. Бот надсилає повідомлення про сполучення лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника). -- Очікувані запити сполучення DM типово обмежено **3 на канал**; додаткові запити ігноруються, доки один не спливе або не буде затверджений. +- **Спливають через 1 годину**. Бот надсилає повідомлення про створення пари лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника). +- Очікувані запити на створення пари для DM стандартно обмежено **3 на канал**; додаткові запити ігноруються, доки один із них не спливе або не буде схвалений. -### Затвердити відправника +### Схвалити відправника ```bash openclaw pairing list telegram openclaw pairing approve telegram ``` -Якщо власника команд ще не налаштовано, затвердження коду сполучення DM також початково налаштовує -`commands.ownerAllowFrom` на затвердженого відправника, наприклад `telegram:123456789`. -Це дає першим налаштуванням явного власника для привілейованих команд і запитів -затвердження exec. Після появи власника подальші затвердження сполучення надають лише доступ -DM; вони не додають більше власників. +Якщо власника команд ще не налаштовано, схвалення коду створення пари для DM також ініціалізує +`commands.ownerAllowFrom` для схваленого відправника, наприклад `telegram:123456789`. +Це дає початковим налаштуванням явного власника для привілейованих команд і запитів +схвалення виконання. Після появи власника подальші схвалення створення пари надають лише +доступ до DM; вони не додають більше власників. Підтримувані канали: `bluebubbles`, `discord`, `feishu`, `googlechat`, `imessage`, `irc`, `line`, `matrix`, `mattermost`, `msteams`, `nextcloud-talk`, `nostr`, `openclaw-weixin`, `signal`, `slack`, `synology-chat`, `telegram`, `twitch`, `whatsapp`, `zalo`, `zalouser`. ### Багаторазові групи відправників -Використовуйте верхньорівневі `accessGroups`, коли той самий набір довірених відправників має застосовуватися до -кількох каналів повідомлень або і до списків дозволених DM, і до групових списків дозволених. +Використовуйте верхньорівневі `accessGroups`, коли один і той самий набір довірених відправників має застосовуватися до +кількох каналів повідомлень або до списків дозволених як для DM, так і для груп. Статичні групи використовують `type: "message.senders"` і посилаються через `accessGroup:` зі списків дозволених каналу: @@ -88,60 +88,60 @@ DM; вони не додають більше власників. Зберігається в `~/.openclaw/credentials/`: - Очікувані запити: `-pairing.json` -- Сховище затвердженого списку дозволених: - - Типовий обліковий запис: `-allowFrom.json` - - Нетиповий обліковий запис: `--allowFrom.json` +- Схвалене сховище списку дозволених: + - Стандартний обліковий запис: `-allowFrom.json` + - Нестандартний обліковий запис: `--allowFrom.json` Поведінка області дії облікового запису: -- Нетипові облікові записи читають/записують лише свій файл списку дозволених з областю дії. -- Типовий обліковий запис використовує каналовий файл списку дозволених без області дії. +- Нестандартні облікові записи читають/записують лише свій файл списку дозволених з областю дії. +- Стандартний обліковий запис використовує файл списку дозволених каналу без області дії. -Ставтеся до них як до конфіденційних (вони керують доступом до вашого асистента). +Ставтеся до них як до чутливих даних (вони контролюють доступ до вашого асистента). -Сховище списку дозволених сполучення призначене для доступу DM. Авторизація груп є окремою. -Затвердження коду сполучення DM автоматично не дозволяє цьому відправнику виконувати групові -команди або керувати ботом у групах. Початкове налаштування першого власника є окремим станом конфігурації -в `commands.ownerAllowFrom`, а доставка групового чату й далі дотримується +Сховище списку дозволених для створення пар призначене для доступу до DM. Авторизація груп окрема. +Схвалення коду створення пари для DM не дозволяє цьому відправнику автоматично виконувати групові +команди або керувати ботом у групах. Початкова ініціалізація першого власника є окремим станом +конфігурації в `commands.ownerAllowFrom`, а доставлення групових чатів і далі дотримується групових списків дозволених каналу (наприклад `groupAllowFrom`, `groups` або перевизначень для окремих груп чи тем залежно від каналу). -## 2) Сполучення пристрою Node (вузли iOS/Android/macOS/headless) +## 2) Створення пари з Node-пристроєм (iOS/Android/macOS/headless Node) -Вузли підключаються до Gateway як **пристрої** з `role: node`. Gateway -створює запит на сполучення пристрою, який потрібно затвердити. +Node підключаються до Gateway як **пристрої** з `role: node`. Gateway +створює запит на створення пари з пристроєм, який потрібно схвалити. -### Сполучення через Telegram (рекомендовано для iOS) +### Створення пари через Telegram (рекомендовано для iOS) -Якщо ви використовуєте Plugin `device-pair`, перше сполучення пристрою можна виконати повністю з Telegram: +Якщо ви використовуєте Plugin `device-pair`, ви можете виконати перше створення пари з пристроєм повністю з Telegram: -1. У Telegram напишіть своєму боту: `/pair` -2. Бот відповідає двома повідомленнями: повідомленням з інструкціями та окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram). +1. У Telegram надішліть повідомлення своєму боту: `/pair` +2. Бот відповість двома повідомленнями: повідомленням з інструкцією та окремим повідомленням із **кодом налаштування** (його легко копіювати/вставляти в Telegram). 3. На телефоні відкрийте застосунок OpenClaw для iOS → Settings → Gateway. 4. Вставте код налаштування й підключіться. -5. Назад у Telegram: `/pair pending` (перегляньте ID запитів, роль і області дії), потім затвердьте. +5. Поверніться в Telegram: `/pair pending` (перегляньте ідентифікатори запитів, роль і області дії), потім схваліть. -Код налаштування — це JSON-пейлоад, закодований у base64, який містить: +Код налаштування — це JSON-навантаження, закодоване в base64, яке містить: - `url`: URL WebSocket Gateway (`ws://...` або `wss://...`) -- `bootstrapToken`: короткоживучий bootstrap-токен для одного пристрою, який використовується для початкового рукостискання сполучення +- `bootstrapToken`: короткоживучий bootstrap-токен для одного пристрою, який використовується для початкового рукостискання створення пари -Цей bootstrap-токен має вбудований bootstrap-профіль сполучення: +Цей bootstrap-токен має вбудований bootstrap-профіль створення пари: -- основний переданий токен `node` лишається `scopes: []` -- будь-який переданий токен `operator` лишається обмеженим bootstrap-списком дозволених: +- основний переданий токен `node` залишається з `scopes: []` +- будь-який переданий токен `operator` залишається обмеженим bootstrap-списком дозволених: `operator.approvals`, `operator.read`, `operator.talk.secrets`, `operator.write` -- перевірки bootstrap-областей дії мають префікс ролі, а не один плоский пул областей дії: - записи областей дії operator задовольняють лише запити operator, а ролі не-operator - усе одно мають запитувати області дії під власним префіксом ролі -- подальша ротація/відкликання токенів лишається обмеженою і затвердженим - контрактом ролі пристрою, і областями дії operator сесії виклику +- перевірки bootstrap-областей дії мають префікс ролі, а не один плаский пул областей дії: + записи області дії оператора задовольняють лише запити оператора, а ролі, що не є операторськими, + все одно мають запитувати області дії під власним префіксом ролі +- подальша ротація/відкликання токена залишається обмеженою як схваленим + контрактом ролі пристрою, так і операторськими областями дії сесії викликача Ставтеся до коду налаштування як до пароля, поки він чинний. -### Затвердити пристрій Node +### Схвалити Node-пристрій ```bash openclaw devices list @@ -149,18 +149,25 @@ openclaw devices approve openclaw devices reject ``` -Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншою -роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється і створюється новий +Коли явне схвалення відхилено через те, що сесію схвалювального paired-пристрою +було відкрито лише з областю дії для створення пари, CLI повторює той самий запит із +`operator.admin`. Це дає наявному paired-пристрою з можливостями адміністратора відновити нове +створення пари для Control UI/браузера без ручного редагування `devices/paired.json`. +Gateway усе одно перевіряє повторне підключення; токени, які не можуть автентифікуватися +з `operator.admin`, залишаються заблокованими. + +Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншими +роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється, і створюється новий `requestId`. -Уже сполучений пристрій не отримує ширший доступ непомітно. Якщо він перепідключається й просить більше областей дії або ширшу роль, OpenClaw лишає наявне затвердження без змін і створює новий очікуваний запит на підвищення. Використовуйте `openclaw devices list`, щоб порівняти поточний затверджений доступ із новим запитаним доступом перед затвердженням. +Уже paired-пристрій не отримує ширший доступ непомітно. Якщо він повторно підключається, запитуючи більше областей дії або ширшу роль, OpenClaw зберігає наявне схвалення без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте `openclaw devices list`, щоб порівняти поточний схвалений доступ із новозапитаним доступом перед схваленням. -### Необов’язкове автоматичне затвердження Node за довіреним CIDR +### Необов’язкове автоматичне схвалення Node з довірених CIDR -Сполучення пристроїв типово лишається ручним. Для суворо контрольованих мереж Node -можна увімкнути автоматичне затвердження першого Node з явними CIDR або точними IP: +Створення пари з пристроєм стандартно залишається ручним. Для суворо контрольованих Node-мереж +ви можете ввімкнути автоматичне схвалення першого Node з явними CIDR або точними IP-адресами: ```json5 { @@ -174,25 +181,25 @@ openclaw devices reject } ``` -Це застосовується лише до нових запитів сполучення `role: node` без запитаних -областей дії. Клієнти operator, browser, Control UI і WebChat усе одно потребують ручного -затвердження. Зміни ролі, області дії, метаданих і публічного ключа також потребують ручного -затвердження. +Це застосовується лише до нових запитів на створення пари `role: node` без запитаних +областей дії. Операторські, браузерні, Control UI та WebChat клієнти все одно потребують ручного +схвалення. Зміни ролі, області дії, метаданих і публічного ключа все одно потребують ручного +схвалення. -### Зберігання стану сполучення Node +### Зберігання стану створення пари з Node Зберігається в `~/.openclaw/devices/`: - `pending.json` (короткоживучий; очікувані запити спливають) -- `paired.json` (сполучені пристрої + токени) +- `paired.json` (paired-пристрої + токени) ### Примітки - Застарілий API `node.pair.*` (CLI: `openclaw nodes pending|approve|reject|remove|rename`) є - окремим сховищем сполучення, яким володіє gateway. WS-вузли все одно потребують сполучення пристрою. -- Запис сполучення є тривалим джерелом істини для затверджених ролей. Активні - токени пристрою лишаються обмеженими цим затвердженим набором ролей; випадковий запис токена - поза затвердженими ролями не створює нового доступу. + окремим сховищем створення пар, яким володіє gateway. WS Node усе одно потребують створення пари з пристроєм. +- Запис створення пари є довготривалим джерелом істини для схвалених ролей. Активні + токени пристроїв залишаються обмеженими цим схваленим набором ролей; випадковий запис токена + поза схваленими ролями не створює нового доступу. ## Пов’язані документи diff --git a/docs/uk/concepts/progress-drafts.md b/docs/uk/concepts/progress-drafts.md index 462c00c05..309fd4fca 100644 --- a/docs/uk/concepts/progress-drafts.md +++ b/docs/uk/concepts/progress-drafts.md @@ -2,27 +2,27 @@ read_when: - Налаштування видимих оновлень прогресу для тривалих ходів чату - Вибір між режимами потокового передавання partial, block і progress - - Пояснення, як OpenClaw оновлює одне повідомлення в каналі під час виконання роботи - - Усунення проблем із чернетками прогресу, окремими повідомленнями про прогрес або резервним механізмом фіналізації -summary: 'Чернетки прогресу: одне видиме повідомлення про перебіг роботи, яке оновлюється під час роботи агента' -title: Чернетки перебігу роботи + - Пояснення того, як OpenClaw оновлює одне повідомлення в каналі під час виконання роботи + - Усунення неполадок із чернетками прогресу, окремими повідомленнями про прогрес або резервним механізмом фіналізації +summary: 'Чернетки прогресу: одне видиме проміжне повідомлення про хід роботи, яке оновлюється, поки агент працює' +title: Чернетки прогресу x-i18n: - generated_at: "2026-05-03T23:27:03Z" + generated_at: "2026-05-03T23:55:07Z" model: gpt-5.5 provider: openai - source_hash: 04e87e81b5b256a3dcd52b70d46e85c80a5d05ecb32df00ccf59782ab47bde2c + source_hash: 079d4b63554fee0fc968027195d2707f2f0a16fa527b0ec81f88baedfe809c1e source_path: concepts/progress-drafts.md workflow: 16 --- -Чернетки прогресу оживляють довгі ходи агента в чаті, не перетворюючи -розмову на стек тимчасових відповідей зі статусом. +Чернетки прогресу роблять тривалі ходи агента живими в чаті, не перетворюючи +розмову на стос тимчасових відповідей зі статусом. -Коли чернетки прогресу ввімкнені, OpenClaw створює одне видиме повідомлення -про роботу в процесі лише після того, як хід доведе, що виконує реальну роботу, -оновлює його, поки агент читає, планує, викликає інструменти або чекає на -схвалення, а потім перетворює цю чернетку на фінальну відповідь, коли канал -може зробити це безпечно. +Коли чернетки прогресу ввімкнено, OpenClaw створює одне видиме повідомлення з +роботою в процесі лише після того, як хід доводить, що справді виконує роботу, +оновлює його, поки агент читає, планує, викликає інструменти або чекає +схвалення, а потім перетворює цю чернетку на фінальну відповідь, коли канал може +зробити це безпечно. ```text Shelling... @@ -31,9 +31,9 @@ Shelling... - preparing reply ``` -Використовуйте чернетки прогресу, коли потрібне одне охайне повідомлення зі +Використовуйте чернетки прогресу, коли вам потрібне одне охайне повідомлення зі статусом під час роботи з великою кількістю інструментів і фінальна відповідь, -коли хід завершено. +коли хід завершиться. ## Швидкий старт @@ -52,37 +52,38 @@ Shelling... ``` Зазвичай цього достатньо. OpenClaw вибере автоматичну однослівну мітку, -зачекає, доки робота триватиме щонайменше п’ять секунд або згенерує другу подію -роботи, додаватиме стислі рядки прогресу, поки відбувається корисна робота, і -пригнічуватиме дублікати окремого прогрес-чату для цього ходу. +зачекає, доки робота триватиме щонайменше п'ять секунд або згенерує другу подію +роботи, додаватиме компактні рядки прогресу, поки відбувається корисна робота, і +приглушить дублікати окремих повідомлень про прогрес для цього ходу. ## Що бачать користувачі Чернетка прогресу має дві частини: -| Частина | Призначення | -| -------------- | ----------------------------------------------------------------- | -| Мітка | Короткий заголовок, наприклад `Thinking...` або `Shelling...`. | -| Рядки прогресу | Стислі оновлення виконання, як-от виклики інструментів, кроки завдань або схвалення. | +| Частина | Призначення | +| -------------- | -------------------------------------------------------------------------- | +| Мітка | Короткий заголовок, як-от `Thinking...` або `Shelling...`. | +| Рядки прогресу | Компактні оновлення запуску з тими самими мітками інструментів та іконками, що й у докладному виводі. | -Мітка з’являється після того, як агент починає змістовну роботу і або -залишається зайнятим п’ять секунд, або генерує другу подію роботи. Відповіді -лише звичайним текстом не показують чернетку прогресу. Рядки прогресу -додаються лише тоді, коли агент генерує корисні оновлення роботи. Фінальна -відповідь замінює чернетку, коли це можливо; інакше OpenClaw надсилає фінальну -відповідь звичайним способом і очищає або припиняє оновлювати чернетку -відповідно до транспорту каналу. +Мітка з'являється після того, як агент починає змістовну роботу й або +залишається зайнятим протягом п'яти секунд, або генерує другу подію роботи. +Відповіді лише простим текстом не показують чернетку прогресу. Рядки прогресу +додаються лише тоді, коли агент генерує корисні оновлення роботи, наприклад +`🛠️ Exec`, `🔎 Web Search` або `✍️ Write: to /tmp/file`. Фінальна відповідь +замінює чернетку, коли це можливо; інакше OpenClaw надсилає фінальну відповідь +звичайним способом і очищає чернетку або припиняє її оновлювати відповідно до +транспорту каналу. ## Вибір режиму `channels..streaming.mode` керує видимою поведінкою роботи в процесі: -| Режим | Найкраще для | Що з’являється в чаті | -| ---------- | -------------------------------- | ------------------------------------------------- | -| `off` | Тихі канали | Лише фінальна відповідь. | -| `partial` | Спостереження за появою тексту відповіді | Одна чернетка, що редагується з найновішим текстом відповіді. | -| `block` | Більші фрагменти попереднього перегляду відповіді | Один попередній перегляд, що оновлюється або доповнюється більшими фрагментами. | -| `progress` | Ходи з великою кількістю інструментів або довгим виконанням | Одна чернетка статусу, потім фінальна відповідь. | +| Режим | Найкраще для | Що з'являється в чаті | +| ---------- | ------------------------------------ | -------------------------------------------------- | +| `off` | Тихих каналів | Лише фінальна відповідь. | +| `partial` | Спостереження за появою тексту відповіді | Одна чернетка, відредагована з найновішим текстом відповіді. | +| `block` | Більших фрагментів попереднього перегляду відповіді | Один попередній перегляд, оновлений або доповнений більшими фрагментами. | +| `progress` | Ходів із великою кількістю інструментів або тривалим виконанням | Одна чернетка статусу, потім фінальна відповідь. | Вибирайте `progress`, коли користувачам важливіше "що відбувається", ніж спостерігати, як текст відповіді транслюється токен за токеном. @@ -91,16 +92,16 @@ Shelling... Вибирайте `block`, коли потрібні оновлення чернетки попереднього перегляду більшими текстовими фрагментами. У Discord і Telegram `streaming.mode: "block"` -усе ще є потоковим попереднім переглядом, а не звичайною блоковою доставкою. -Використовуйте `streaming.block.enabled` або застарілий `blockStreaming`, коли -потрібні звичайні блокові відповіді. +досі означає потокове передавання попереднього перегляду, а не звичайну доставку +блоків. Використовуйте `streaming.block.enabled` або застарілий `blockStreaming`, +коли потрібні звичайні блокові відповіді. ## Налаштування міток Мітки прогресу розташовані в `channels..streaming.progress`. -Типова мітка — `auto`, яка вибирає з вбудованого пулу OpenClaw -однослівних міток із трьома крапками: +Типова мітка — `auto`, яка вибирає з вбудованого в OpenClaw набору однослівних +міток із трьома крапками: ```text Thinking... @@ -142,7 +143,7 @@ Surfacing... } ``` -Використовуйте власний автоматичний пул міток: +Використовуйте власний автоматичний набір міток: ```json5 { @@ -179,9 +180,9 @@ Surfacing... ## Керування рядками прогресу -Рядки прогресу ввімкнені типово в режимі progress. Вони походять із реальних -подій виконання: запусків інструментів, оновлень елементів, планів завдань, -схвалень, виводу команд, підсумків патчів і подібної активності агента. +Рядки прогресу ввімкнено за замовчуванням у режимі прогресу. Вони походять із +реальних подій запуску: запусків інструментів, оновлень елементів, планів +завдань, схвалень, виводу команд, підсумків патчів і схожої активності агента. Обмежте кількість рядків, які залишаються видимими: @@ -200,7 +201,7 @@ Surfacing... } ``` -Збережіть єдину чернетку прогресу, але приховайте рядки інструментів і завдань: +Збережіть одну чернетку прогресу, але приховайте рядки інструментів і завдань: ```json5 { @@ -217,22 +218,22 @@ Surfacing... } ``` -З `toolProgress: false` OpenClaw усе ще пригнічує старіші окремі повідомлення -про прогрес інструментів для цього ходу. Канал залишається візуально тихим до -фінальної відповіді, крім мітки, якщо її налаштовано. +З `toolProgress: false` OpenClaw усе одно приглушує старі окремі повідомлення про +прогрес інструментів для цього ходу. Канал залишається візуально тихим до +фінальної відповіді, за винятком мітки, якщо її налаштовано. ## Поведінка каналів -Кожен канал використовує найчистіший транспорт, який підтримує: +Кожен канал використовує найчистіший транспорт, який він підтримує: -| Канал | Транспорт прогресу | Примітки | -| --------------- | -------------------------------------- | --------------------------------------------------------------------- | -| Discord | Надіслати одне повідомлення, потім редагувати його. | Фінальний текст редагується на місці, коли він уміщується в одне безпечне повідомлення попереднього перегляду. | -| Matrix | Надіслати одну подію, потім редагувати її. | Конфігурація потокового передавання на рівні облікового запису керує чернетками на рівні облікового запису. | -| Microsoft Teams | Нативний потік Teams в особистих чатах. | `streaming.mode: "block"` зіставляється з блоковою доставкою Teams. | -| Slack | Нативний потік або редагований допис-чернетка. | Доступність треду впливає на те, чи можна використовувати нативне потокове передавання. | -| Telegram | Надіслати одне повідомлення, потім редагувати його. | Старіші видимі чернетки можуть бути замінені, щоб фінальні часові позначки залишалися корисними. | -| Mattermost | Редагований допис-чернетка. | Активність інструментів згортається в той самий допис у стилі чернетки. | +| Канал | Транспорт прогресу | Примітки | +| --------------- | ------------------------------------ | --------------------------------------------------------------------- | +| Discord | Надіслати одне повідомлення, потім редагувати його. | Фінальний текст редагується на місці, коли вміщується в одне безпечне повідомлення попереднього перегляду. | +| Matrix | Надіслати одну подію, потім редагувати її. | Налаштування потокового передавання на рівні акаунта керує чернетками на рівні акаунта. | +| Microsoft Teams | Нативний потік Teams в особистих чатах. | `streaming.mode: "block"` зіставляється з блоковою доставкою Teams. | +| Slack | Нативний потік або редагована чернетка допису. | Доступність гілки впливає на те, чи можна використовувати нативне потокове передавання. | +| Telegram | Надіслати одне повідомлення, потім редагувати його. | Старіші видимі чернетки можуть бути замінені, щоб фінальні часові мітки залишалися корисними. | +| Mattermost | Редагована чернетка допису. | Активність інструментів згортається в той самий допис у стилі чернетки. | Канали без безпечної підтримки редагування зазвичай повертаються до індикаторів набору тексту або доставки лише фінальної відповіді. @@ -243,10 +244,10 @@ Surfacing... - Якщо чернетка може безпечно стати фінальною відповіддю, OpenClaw редагує її на місці. - Якщо канал використовує нативне потокове передавання прогресу, OpenClaw фіналізує цей потік, коли нативний транспорт приймає фінальний текст. -- Якщо фінальна відповідь містить медіа, запит на схвалення, явну ціль відповіді, надто багато фрагментів або невдале редагування/надсилання, OpenClaw надсилає фінальну відповідь через звичайний шлях доставки каналу. +- Якщо фінальна відповідь містить медіа, запит на схвалення, явну ціль відповіді, забагато фрагментів або невдале редагування/надсилання, OpenClaw надсилає фінальну відповідь через звичайний шлях доставки каналу. Резервний шлях є навмисним. Краще надіслати нову фінальну відповідь, ніж -втратити текст, неправильно прив’язати відповідь до треду або перезаписати +втратити текст, неправильно прив'язати відповідь до гілки або перезаписати чернетку корисним навантаженням, яке канал не може безпечно представити. ## Усунення несправностей @@ -254,42 +255,42 @@ Surfacing... **Я бачу лише фінальну відповідь.** Перевірте, що `channels..streaming.mode` встановлено на `progress` для -облікового запису або каналу, який обробив повідомлення. Деякі групові шляхи -або шляхи відповіді з цитатою можуть вимикати попередні перегляди чернеток для -ходу, коли канал не може безпечно редагувати правильне повідомлення. +акаунта або каналу, який обробив повідомлення. Деякі шляхи груп або відповідей із +цитуванням можуть вимикати попередні перегляди чернеток для ходу, коли канал не +може безпечно редагувати правильне повідомлення. **Я бачу мітку, але не бачу рядків інструментів.** Перевірте `streaming.progress.toolProgress`. Якщо це `false`, OpenClaw зберігає -поведінку єдиної чернетки, але приховує рядки прогресу інструментів і завдань. +поведінку з однією чернеткою, але приховує рядки прогресу інструментів і завдань. **Я бачу нове фінальне повідомлення замість відредагованої чернетки.** Це резервний механізм безпеки. Таке може статися для відповідей із медіа, довгих відповідей, явних цілей відповіді, старих чернеток Telegram, відсутніх -цілей тредів Slack, видалених повідомлень попереднього перегляду або невдалої +цілей гілок Slack, видалених повідомлень попереднього перегляду або невдалої фіналізації нативного потоку. -**Я все ще бачу окремі повідомлення про прогрес.** +**Я досі бачу окремі повідомлення про прогрес.** -Режим progress пригнічує типові окремі повідомлення про прогрес інструментів, -коли чернетка активна. Якщо окремі повідомлення все ще з’являються, перевірте, -що хід справді використовує режим progress, а не `streaming.mode: "off"` або -шлях каналу, який не може створити чернетку для цього повідомлення. +Режим прогресу приглушує типові окремі повідомлення про прогрес інструментів, +коли чернетка активна. Якщо окремі повідомлення все ще з'являються, перевірте, +що хід справді використовує режим прогресу, а не `streaming.mode: "off"` або шлях +каналу, який не може створити чернетку для цього повідомлення. **Teams поводиться інакше, ніж Discord або Telegram.** Microsoft Teams використовує нативний потік в особистих чатах замість універсального транспорту попереднього перегляду з надсиланням і редагуванням. -Teams також трактує `streaming.mode: "block"` як блокову доставку Teams, -оскільки він не має такого самого режиму блокового попереднього перегляду -чернеток, який використовують Discord і Telegram. +Teams також трактує `streaming.mode: "block"` як блокову доставку Teams, бо не +має такого самого блокового режиму попереднього перегляду чернеток, який +використовують Discord і Telegram. -## Пов’язане +## Пов'язане -- [Потокове передавання та фрагментація](/uk/concepts/streaming) +- [Потокове передавання та розбиття на фрагменти](/uk/concepts/streaming) - [Повідомлення](/uk/concepts/messages) -- [Конфігурація каналів](/uk/gateway/config-channels) +- [Налаштування каналів](/uk/gateway/config-channels) - [Discord](/uk/channels/discord) - [Matrix](/uk/channels/matrix) - [Microsoft Teams](/uk/channels/msteams) diff --git a/docs/uk/gateway/operator-scopes.md b/docs/uk/gateway/operator-scopes.md index 8804e9580..dcdfd07b0 100644 --- a/docs/uk/gateway/operator-scopes.md +++ b/docs/uk/gateway/operator-scopes.md @@ -1,22 +1,22 @@ --- read_when: - - Налагодження помилок через відсутню область дії оператора - - Перегляд схвалень сполучення пристрою або Node + - Налагодження помилок, пов’язаних із відсутньою областю дії оператора + - Перегляд схвалень для сполучення пристрою або Node - Додавання або класифікація RPC-методів Gateway -summary: Ролі операторів, області доступу та перевірки на етапі затвердження для клієнтів Gateway +summary: Ролі операторів, області дії та перевірки під час затвердження для клієнтів Gateway title: Області дії оператора x-i18n: - generated_at: "2026-05-03T00:43:11Z" + generated_at: "2026-05-03T23:54:54Z" model: gpt-5.5 provider: openai - source_hash: 48f59f96b41333af9124ad4083ac5442eedb2d6cebdfff74e3ba256f06d36add + source_hash: f05d6bdbf9bdad2aef1c9664bb7ebb4b6241334b8aefac7993104e9977e40450 source_path: gateway/operator-scopes.md workflow: 16 --- Області дії оператора визначають, що клієнт Gateway може робити після автентифікації. -Вони є захисним механізмом площини керування всередині одного довіреного домену оператора Gateway, -а не ізоляцією від ворожого багатокористувацького середовища. Якщо вам потрібне сильне розділення між +Вони є запобіжником площини керування всередині одного довіреного операторського домену Gateway, +а не ізоляцією від ворожих багатьох орендарів. Якщо вам потрібне сильне розділення між людьми, командами або машинами, запускайте окремі Gateways під окремими користувачами ОС або на окремих хостах. @@ -27,41 +27,41 @@ x-i18n: Клієнти Gateway WebSocket підключаються з однією роллю: -- `operator`: клієнти площини керування, як-от CLI, Control UI, автоматизація та +- `operator`: клієнти площини керування, такі як CLI, Control UI, автоматизація та довірені допоміжні процеси. -- `node`: хости можливостей, як-от macOS, iOS, Android або безголові вузли, які +- `node`: хости можливостей, такі як macOS, iOS, Android або безголові вузли, які надають команди через `node.invoke`. -RPC-методи оператора потребують ролі `operator`. Методи, що походять від Node, +Методи RPC оператора потребують ролі `operator`. Методи, що походять від Node, потребують ролі `node`. ## Рівні областей дії -| Область дії | Значення | -| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `operator.read` | Статус лише для читання, списки, каталог, журнали, читання сесій та інші виклики площини керування, які не змінюють стан. | -| `operator.write` | Звичайні операторські дії, що змінюють стан, як-от надсилання повідомлень, виклик інструментів, оновлення налаштувань розмови/голосу та ретрансляція команд Node. Також задовольняє `operator.read`. | -| `operator.admin` | Адміністративний доступ до площини керування. Задовольняє кожну область дії `operator.*`. Потрібна для зміни конфігурації, оновлень, нативних хуків, чутливих зарезервованих просторів імен та високоризикових схвалень. | -| `operator.pairing` | Керування сполученням пристроїв і Node, зокрема перелік, схвалення, відхилення, видалення, ротація та відкликання записів сполучення або токенів пристроїв. | -| `operator.approvals` | API схвалення exec і Plugin. | -| `operator.talk.secrets` | Читання конфігурації Talk з включеними секретами. | +| Область дії | Значення | +| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `operator.read` | Стан лише для читання, списки, каталог, журнали, читання сеансів та інші виклики площини керування без мутацій. | +| `operator.write` | Звичайні мутаційні дії оператора, такі як надсилання повідомлень, виклик інструментів, оновлення налаштувань розмови/голосу та ретрансляція команд Node. Також задовольняє `operator.read`. | +| `operator.admin` | Адміністративний доступ до площини керування. Задовольняє кожну область дії `operator.*`. Потрібна для мутації конфігурації, оновлень, нативних хуків, чутливих зарезервованих просторів імен та схвалень високого ризику. | +| `operator.pairing` | Керування сполученням пристроїв і Node, зокрема перелік, схвалення, відхилення, видалення, ротація та відкликання записів сполучення або токенів пристроїв. | +| `operator.approvals` | API схвалення виконання та plugin. | +| `operator.talk.secrets` | Читання конфігурації Talk з включеними секретами. | Невідомі майбутні області дії `operator.*` потребують точного збігу, якщо викликач не має `operator.admin`. ## Область дії методу — лише перший бар’єр -Кожен RPC Gateway має область дії методу з найменшими привілеями. Ця область дії методу визначає, +Кожен RPC Gateway має область дії методу з мінімальними привілеями. Ця область дії методу визначає, чи може запит дійти до обробника. Деякі обробники потім застосовують суворіші перевірки під час схвалення на основі конкретної речі, яку схвалюють або змінюють. Приклади: -- `device.pair.approve` доступний з `operator.pairing`, але схвалення - операторського пристрою може створювати або зберігати лише ті області дії, які викликач уже має. -- `node.pair.approve` доступний з `operator.pairing`, а потім виводить додаткові - області дії для схвалення зі списку команд Node, що очікують. -- `chat.send` зазвичай є методом з областю дії на запис, але постійні `/config set` +- `device.pair.approve` доступний із `operator.pairing`, але схвалення + операторського пристрою може лише створити або зберегти області дії, які викликач уже має. +- `node.pair.approve` доступний із `operator.pairing`, а потім виводить додаткові + області дії схвалення зі списку очікуваних команд Node. +- `chat.send` зазвичай є методом з областю дії запису, але постійні `/config set` і `/config unset` потребують `operator.admin` на рівні команди. Це дає операторам із нижчими областями дії виконувати низькоризикові дії сполучення, не роблячи @@ -69,48 +69,50 @@ RPC-методи оператора потребують ролі `operator`. М ## Схвалення сполучення пристроїв -Записи сполучення пристроїв є довговічним джерелом схвалених ролей і областей дії. +Записи сполучення пристроїв є надійним джерелом схвалених ролей і областей дії. Уже сполучені пристрої не отримують ширший доступ непомітно: повторні підключення, які запитують ширшу роль або ширші області дії, створюють новий запит на оновлення, що очікує. Під час схвалення запиту пристрою: -- Запит без ролі оператора не потребує схвалення області дії операторського токена. +- Запит без ролі оператора не потребує схвалення області дії токена оператора. - Запит на `operator.read`, `operator.write`, `operator.approvals`, `operator.pairing` або `operator.talk.secrets` потребує, щоб викликач мав ці області дії або `operator.admin`. - Запит на `operator.admin` потребує `operator.admin`. -- Запит на відновлення без явних областей дії може успадкувати наявні області дії - операторського токена. Якщо цей наявний токен має адміністративну область дії, схвалення все одно потребує +- Запит на відновлення без явних областей дії може успадкувати наявні області дії токена + оператора. Якщо цей наявний токен має область дії адміністратора, схвалення все одно потребує `operator.admin`. -Для токенних сесій сполучених пристроїв керування обмежене власним записом, якщо викликач -також не має `operator.admin`: викликачі без прав адміністратора можуть ротувати, відкликати або видаляти лише -власний запис пристрою. +Для сеансів токенів сполучених пристроїв керування має власну область дії, якщо викликач +також не має `operator.admin`: викликачі без прав адміністратора бачать лише власні записи сполучення, +можуть схвалювати або відхиляти лише власний запит, що очікує, і можуть ротувати, відкликати або +видаляти лише власний запис пристрою. ## Схвалення сполучення Node -Застарілі `node.pair.*` використовують окреме сховище сполучення Node, що належить Gateway. WS-вузли -використовують сполучення пристрою з `role: node`, але застосовується той самий словник рівнів схвалення. +Застарілий `node.pair.*` використовує окреме сховище сполучень Node, яким володіє Gateway. WS-вузли +використовують сполучення пристроїв із `role: node`, але застосовується той самий словник +рівнів схвалення. `node.pair.approve` використовує список команд запиту, що очікує, щоб вивести додаткові потрібні області дії: - Запит без команд: `operator.pairing` -- Команди Node без exec: `operator.pairing` + `operator.write` +- Команди Node без виконання: `operator.pairing` + `operator.write` - `system.run`, `system.run.prepare` або `system.which`: `operator.pairing` + `operator.admin` -Сполучення Node встановлює ідентичність і довіру. Воно не замінює власну -політику схвалення exec `system.run` цього Node. +Сполучення Node встановлює ідентичність і довіру. Воно не замінює власну політику +схвалення виконання `system.run` цього Node. -## Автентифікація спільним секретом +## Автентифікація зі спільним секретом -Автентифікація за спільним токеном/паролем Gateway розглядається як довірений операторський доступ для +Автентифікація зі спільним токеном/паролем Gateway розглядається як довірений операторський доступ для цього Gateway. HTTP-поверхні, сумісні з OpenAI, і `/tools/invoke` відновлюють -звичайний повний набір областей дії оператора за замовчуванням для bearer-автентифікації спільним секретом, навіть якщо +звичайний повний стандартний набір областей дії оператора для bearer-автентифікації зі спільним секретом, навіть якщо викликач надсилає вужчі оголошені області дії. -Режими з ідентичністю, як-от автентифікація через довірений проксі або приватний вхід `none`, -усе ще можуть враховувати явно оголошені області дії. Використовуйте окремі Gateways для справжнього +Режими з ідентичністю, такі як автентифікація через довірений проксі або приватний вхід `none`, +все ще можуть враховувати явно оголошені області дії. Використовуйте окремі Gateways для справжнього розділення меж довіри.