chore(i18n): refresh uk translations
This commit is contained in:
parent
cbba24e45c
commit
72d4f76ef2
@ -1,38 +1,38 @@
|
||||
---
|
||||
read_when:
|
||||
- Зміна поведінки групового чату або обмеження за згадками
|
||||
- Змінення поведінки групового чату або обмеження за згадуваннями
|
||||
sidebarTitle: Groups
|
||||
summary: Поведінка групових чатів у різних середовищах (Discord/iMessage/Matrix/Microsoft Teams/Signal/Slack/Telegram/WhatsApp/Zalo)
|
||||
summary: Поведінка групового чату на різних поверхнях (Discord/iMessage/Matrix/Microsoft Teams/Signal/Slack/Telegram/WhatsApp/Zalo)
|
||||
title: Групи
|
||||
x-i18n:
|
||||
generated_at: "2026-05-01T23:09:52Z"
|
||||
generated_at: "2026-05-03T09:36:58Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 5cc33dbbcf5504cae5caa003b7427d99f5c1a2d7c850dedd5d1f58a2fe44fa04
|
||||
source_hash: 6fd4fcaa8335f1dc4b4b1a719d6654ab0c10530f74284269ed6205dd5f87c116
|
||||
source_path: channels/groups.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw обробляє групові чати узгоджено на різних поверхнях: Discord, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo.
|
||||
OpenClaw обробляє групові чати послідовно на всіх поверхнях: Discord, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo.
|
||||
|
||||
## Вступ для початківців (2 хвилини)
|
||||
|
||||
OpenClaw "живе" у ваших власних облікових записах для обміну повідомленнями. Окремого користувача-бота WhatsApp немає. Якщо **ви** перебуваєте в групі, OpenClaw може бачити цю групу й відповідати там.
|
||||
OpenClaw «живе» у ваших власних облікових записах месенджерів. Окремого користувача-бота WhatsApp немає. Якщо **ви** є в групі, OpenClaw може бачити цю групу й відповідати в ній.
|
||||
|
||||
Типова поведінка:
|
||||
Стандартна поведінка:
|
||||
|
||||
- Групи обмежені (`groupPolicy: "allowlist"`).
|
||||
- Для відповідей потрібна згадка, якщо ви явно не вимкнули шлюзування за згадкою.
|
||||
- Звичайні фінальні відповіді в групах/каналах типово приватні. Видимий вивід у кімнату використовує інструмент `message`.
|
||||
- Для відповідей потрібна згадка, якщо ви явно не вимкнули шлюзування за згадками.
|
||||
- Звичайні фінальні відповіді в групах/каналах за замовчуванням приватні. Видимий вивід у кімнату використовує інструмент `message`.
|
||||
|
||||
Переклад: відправники з allowlist можуть запускати OpenClaw, згадуючи його.
|
||||
Іншими словами: відправники зі списку дозволених можуть запустити OpenClaw, згадавши його.
|
||||
|
||||
<Note>
|
||||
**Коротко**
|
||||
|
||||
- **Доступ до DM** контролюється через `*.allowFrom`.
|
||||
- **Доступ до груп** контролюється через `*.groupPolicy` + allowlist (`*.groups`, `*.groupAllowFrom`).
|
||||
- **Запуск відповіді** контролюється шлюзуванням за згадкою (`requireMention`, `/activation`).
|
||||
- **Доступ до груп** контролюється через `*.groupPolicy` + списки дозволених (`*.groups`, `*.groupAllowFrom`).
|
||||
- **Запуск відповіді** контролюється шлюзуванням за згадками (`requireMention`, `/activation`).
|
||||
|
||||
</Note>
|
||||
|
||||
@ -47,18 +47,18 @@ otherwise -> reply
|
||||
|
||||
## Видимі відповіді
|
||||
|
||||
Для групових/канальних кімнат OpenClaw типово використовує `messages.groupChat.visibleReplies: "message_tool"`.
|
||||
Це означає, що агент усе одно обробляє хід і може оновлювати стан пам’яті/сесії, але його звичайна фінальна відповідь не публікується автоматично назад у кімнату. Щоб говорити видимо, агент використовує `message(action=send)`.
|
||||
Для групових/канальних кімнат OpenClaw за замовчуванням використовує `messages.groupChat.visibleReplies: "message_tool"`.
|
||||
`openclaw doctor --fix` записує це значення за замовчуванням у конфігурації налаштованих каналів, де його пропущено.
|
||||
Це означає, що агент усе ще обробляє хід і може оновлювати стан пам’яті/сесії, але його звичайна фінальна відповідь не публікується автоматично назад у кімнату. Щоб говорити видимо, агент використовує `message(action=send)`.
|
||||
|
||||
Якщо інструмент message недоступний за активною політикою інструментів, OpenClaw
|
||||
повертається до автоматичних видимих відповідей замість тихого приглушення відповіді.
|
||||
Якщо інструмент повідомлень недоступний у межах активної політики інструментів, OpenClaw повертається до автоматичних видимих відповідей замість мовчазного придушення відповіді.
|
||||
`openclaw doctor` попереджає про цю невідповідність.
|
||||
|
||||
Для прямих чатів і будь-якого іншого початкового ходу використовуйте `messages.visibleReplies: "message_tool"`, щоб застосувати таку саму поведінку видимих відповідей тільки через інструмент глобально. Тестові harness також можуть вибрати це як свій типовий варіант, коли значення не задано; harness Codex робить це для прямих чатів у режимі Codex. `messages.groupChat.visibleReplies` залишається специфічнішим перевизначенням для групових/канальних кімнат.
|
||||
Для прямих чатів і будь-якого іншого початкового ходу використовуйте `messages.visibleReplies: "message_tool"`, щоб застосувати таку саму поведінку видимих відповідей лише через інструмент глобально. Тестові середовища також можуть вибрати це як своє незадане значення за замовчуванням; середовище Codex робить це для прямих чатів у режимі Codex. `messages.groupChat.visibleReplies` залишається конкретнішим перевизначенням для групових/канальних кімнат.
|
||||
|
||||
Це замінює старий шаблон примушування моделі відповідати `NO_REPLY` для більшості ходів у режимі спостереження. У режимі тільки через інструмент відсутність видимої дії просто означає не викликати інструмент message.
|
||||
Це замінює старий шаблон, коли модель змушували відповідати `NO_REPLY` для більшості ходів у режимі спостереження. У режимі лише через інструмент не робити нічого видимого просто означає не викликати інструмент повідомлень.
|
||||
|
||||
Індикатори набору тексту все ще надсилаються, поки агент працює в режимі тільки через інструмент. Типовий режим набору тексту для груп підвищується з "message" до "instant" для цих ходів, тому що звичайного тексту повідомлення асистента може ніколи не бути до того, як агент вирішить, чи викликати інструмент message. Явна конфігурація режиму набору тексту все ще має пріоритет.
|
||||
Індикатори набору тексту все ще надсилаються, поки агент працює в режимі лише через інструмент. Стандартний режим набору тексту для груп підвищується з "message" до "instant" для цих ходів, бо звичайний текст повідомлення асистента може взагалі не з’явитися до того, як агент вирішить, чи викликати інструмент повідомлень. Явна конфігурація режиму набору тексту все ще має пріоритет.
|
||||
|
||||
Щоб відновити застарілі автоматичні фінальні відповіді для групових/канальних кімнат:
|
||||
|
||||
@ -72,10 +72,9 @@ otherwise -> reply
|
||||
}
|
||||
```
|
||||
|
||||
Gateway гаряче перезавантажує конфігурацію `messages` після збереження файла. Перезапускайте лише
|
||||
коли спостереження за файлами або перезавантаження конфігурації вимкнено в розгортанні.
|
||||
Gateway гаряче перезавантажує конфігурацію `messages` після збереження файла. Перезапуск потрібен лише тоді, коли відстеження файлів або перезавантаження конфігурації вимкнено в розгортанні.
|
||||
|
||||
Щоб вимагати, щоб видимий вивід проходив через інструмент message для кожного початкового чату:
|
||||
Щоб вимагати, аби видимий вивід для кожного початкового чату проходив через інструмент повідомлень:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -85,29 +84,29 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
}
|
||||
```
|
||||
|
||||
Нативні slash-команди (Discord, Telegram та інші поверхні з підтримкою нативних команд) обходять `visibleReplies: "message_tool"` і завжди відповідають видимо, щоб нативний для каналу командний UI отримав очікувану відповідь. Це стосується лише перевірених нативних командних ходів; набрані текстом команди `/...` і звичайні ходи чату все ще дотримуються налаштованого типового значення для груп.
|
||||
Нативні slash-команди (Discord, Telegram та інші поверхні з підтримкою нативних команд) обходять `visibleReplies: "message_tool"` і завжди відповідають видимо, щоб нативний для каналу інтерфейс команд отримав очікувану відповідь. Це застосовується лише до перевірених ходів нативних команд; текстово введені команди `/...` і звичайні ходи чату все ще дотримуються налаштованого групового значення за замовчуванням.
|
||||
|
||||
## Видимість контексту та allowlist
|
||||
## Видимість контексту та списки дозволених
|
||||
|
||||
У безпеці груп задіяні два різні елементи керування:
|
||||
У безпеці груп беруть участь два різні механізми керування:
|
||||
|
||||
- **Авторизація запуску**: хто може запускати агента (`groupPolicy`, `groups`, `groupAllowFrom`, allowlist для конкретних каналів).
|
||||
- **Видимість контексту**: який додатковий контекст вставляється в модель (текст відповіді, цитати, історія треду, переслані метадані).
|
||||
- **Авторизація запуску**: хто може запустити агента (`groupPolicy`, `groups`, `groupAllowFrom`, списки дозволених, специфічні для каналу).
|
||||
- **Видимість контексту**: який додатковий контекст додається до моделі (текст відповіді, цитати, історія треду, метадані пересилання).
|
||||
|
||||
Типово OpenClaw надає пріоритет звичайній поведінці чату й здебільшого зберігає контекст у тому вигляді, у якому його отримано. Це означає, що allowlist передусім визначають, хто може запускати дії, а не є універсальною межею редагування для кожного процитованого чи історичного фрагмента.
|
||||
За замовчуванням OpenClaw надає пріоритет звичайній поведінці чату й здебільшого зберігає контекст таким, яким його отримано. Це означає, що списки дозволених передусім визначають, хто може запускати дії, а не є універсальною межею редагування для кожного цитованого чи історичного фрагмента.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Поточна поведінка залежить від каналу">
|
||||
- Деякі канали вже застосовують фільтрацію за відправником для додаткового контексту в окремих шляхах (наприклад, початкове наповнення треду Slack, пошуки відповідей/тредів Matrix).
|
||||
- Інші канали все ще передають контекст цитати/відповіді/пересилання в отриманому вигляді.
|
||||
- Деякі канали вже застосовують фільтрацію за відправником для додаткового контексту в окремих шляхах (наприклад, початкове заповнення тредів Slack, пошуки відповідей/тредів Matrix).
|
||||
- Інші канали все ще передають контекст цитат/відповідей/пересилань таким, яким його отримано.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Напрям посилення захисту (заплановано)">
|
||||
- `contextVisibility: "all"` (типово) зберігає поточну поведінку в отриманому вигляді.
|
||||
- `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників з allowlist.
|
||||
- `contextVisibility: "all"` (за замовчуванням) зберігає поточну поведінку «як отримано».
|
||||
- `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників зі списку дозволених.
|
||||
- `contextVisibility: "allowlist_quote"` — це `allowlist` плюс один явний виняток для цитати/відповіді.
|
||||
|
||||
Поки цю модель посилення захисту не буде узгоджено реалізовано в усіх каналах, очікуйте відмінностей залежно від поверхні.
|
||||
Доки цю модель посилення захисту не реалізовано послідовно в усіх каналах, очікуйте відмінностей між поверхнями.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -116,42 +115,42 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
|
||||
Якщо ви хочете...
|
||||
|
||||
| Мета | Що встановити |
|
||||
| Мета | Що налаштувати |
|
||||
| -------------------------------------------- | ---------------------------------------------------------- |
|
||||
| Дозволити всі групи, але відповідати лише на @згадки | `groups: { "*": { requireMention: true } }` |
|
||||
| Вимкнути всі групові відповіді | `groupPolicy: "disabled"` |
|
||||
| Лише конкретні групи | `groups: { "<group-id>": { ... } }` (без ключа `"*"`) |
|
||||
| Лише ви можете запускати в групах | `groupPolicy: "allowlist"`, `groupAllowFrom: ["+1555..."]` |
|
||||
| Вимкнути всі групові відповіді | `groupPolicy: "disabled"` |
|
||||
| Лише конкретні групи | `groups: { "<group-id>": { ... } }` (без ключа `"*"`) |
|
||||
| Лише ви можете запускати в групах | `groupPolicy: "allowlist"`, `groupAllowFrom: ["+1555..."]` |
|
||||
| Повторно використовувати один набір довірених відправників у різних каналах | `groupAllowFrom: ["accessGroup:operators"]` |
|
||||
|
||||
Для багаторазових allowlist відправників див. [Групи доступу](/uk/channels/access-groups).
|
||||
Про багаторазові списки дозволених відправників див. [Групи доступу](/uk/channels/access-groups).
|
||||
|
||||
## Ключі сесій
|
||||
|
||||
- Групові сесії використовують ключі сесій `agent:<agentId>:<channel>:group:<id>` (кімнати/канали використовують `agent:<agentId>:<channel>:channel:<id>`).
|
||||
- Теми форуму Telegram додають `:topic:<threadId>` до ідентифікатора групи, щоб кожна тема мала власну сесію.
|
||||
- Теми форумів Telegram додають `:topic:<threadId>` до ідентифікатора групи, щоб кожна тема мала власну сесію.
|
||||
- Прямі чати використовують основну сесію (або окрему для кожного відправника, якщо налаштовано).
|
||||
- Heartbeat пропускаються для групових сесій.
|
||||
- Heartbeats пропускаються для групових сесій.
|
||||
|
||||
<a id="pattern-personal-dms-public-groups-single-agent"></a>
|
||||
|
||||
## Шаблон: особисті DM + публічні групи (один агент)
|
||||
|
||||
Так — це добре працює, якщо ваш "особистий" трафік — це **DM**, а ваш "публічний" трафік — це **групи**.
|
||||
Так — це добре працює, якщо ваш «особистий» трафік — це **DM**, а ваш «публічний» трафік — це **групи**.
|
||||
|
||||
Чому: у режимі одного агента DM зазвичай потрапляють в **основний** ключ сесії (`agent:main:main`), тоді як групи завжди використовують **неосновні** ключі сесій (`agent:main:<channel>:group:<id>`). Якщо ви вмикаєте ізоляцію з `mode: "non-main"`, ці групові сесії запускаються в налаштованому бекенді ізоляції, тоді як ваша основна DM-сесія залишається на хості. Docker є типовим бекендом, якщо ви не виберете інший.
|
||||
Чому: у режимі одного агента DM зазвичай потрапляють в **основний** ключ сесії (`agent:main:main`), тоді як групи завжди використовують **неосновні** ключі сесій (`agent:main:<channel>:group:<id>`). Якщо ввімкнути sandboxing з `mode: "non-main"`, ці групові сесії працюватимуть у налаштованому бекенді пісочниці, тоді як ваша основна сесія DM залишатиметься на хості. Docker є стандартним бекендом, якщо ви не виберете інший.
|
||||
|
||||
Це дає вам один "мозок" агента (спільний робочий простір + пам’ять), але дві позиції виконання:
|
||||
Це дає вам один агентський «мозок» (спільний робочий простір + пам’ять), але дві позиції виконання:
|
||||
|
||||
- **DM**: повні інструменти (хост)
|
||||
- **Групи**: ізоляція + обмежені інструменти
|
||||
- **Групи**: пісочниця + обмежені інструменти
|
||||
|
||||
<Note>
|
||||
Якщо вам потрібні справді окремі робочі простори/персони ("особисте" і "публічне" ніколи не повинні змішуватися), використовуйте другого агента + прив’язки. Див. [Маршрутизація кількох агентів](/uk/concepts/multi-agent).
|
||||
Якщо вам потрібні справді окремі робочі простори/персони («особисте» й «публічне» ніколи не мають змішуватися), використовуйте другого агента + прив’язки. Див. [Маршрутизація кількох агентів](/uk/concepts/multi-agent).
|
||||
</Note>
|
||||
|
||||
<Tabs>
|
||||
<Tab title="DM на хості, групи в ізоляції">
|
||||
<Tab title="DM на хості, групи в пісочниці">
|
||||
```json5
|
||||
{
|
||||
agents: {
|
||||
@ -175,8 +174,8 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="Групи бачать лише папку з allowlist">
|
||||
Хочете, щоб "групи могли бачити лише папку X" замість "без доступу до хоста"? Залиште `workspaceAccess: "none"` і змонтуйте в ізольоване середовище лише шляхи з allowlist:
|
||||
<Tab title="Групи бачать лише папку зі списку дозволених">
|
||||
Хочете «групи можуть бачити лише папку X» замість «немає доступу до хоста»? Залиште `workspaceAccess: "none"` і змонтуйте в пісочницю лише дозволені шляхи:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -203,13 +202,13 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
|
||||
Пов’язане:
|
||||
|
||||
- Ключі конфігурації та типові значення: [Конфігурація Gateway](/uk/gateway/config-agents#agentsdefaultssandbox)
|
||||
- Налагодження, чому інструмент заблоковано: [Ізоляція проти політики інструментів проти підвищених прав](/uk/gateway/sandbox-vs-tool-policy-vs-elevated)
|
||||
- Подробиці монтувань bind: [Ізоляція](/uk/gateway/sandboxing#custom-bind-mounts)
|
||||
- Ключі конфігурації та стандартні значення: [Конфігурація Gateway](/uk/gateway/config-agents#agentsdefaultssandbox)
|
||||
- Налагодження, чому інструмент заблоковано: [Пісочниця проти політики інструментів проти підвищених прав](/uk/gateway/sandbox-vs-tool-policy-vs-elevated)
|
||||
- Деталі bind mounts: [Sandboxing](/uk/gateway/sandboxing#custom-bind-mounts)
|
||||
|
||||
## Мітки відображення
|
||||
## Відображувані мітки
|
||||
|
||||
- Мітки UI використовують `displayName`, коли доступно, у форматі `<channel>:<token>`.
|
||||
- Мітки UI використовують `displayName`, коли він доступний, у форматі `<channel>:<token>`.
|
||||
- `#room` зарезервовано для кімнат/каналів; групові чати використовують `g-<slug>` (нижній регістр, пробіли -> `-`, зберігати `#@+._-`).
|
||||
|
||||
## Політика груп
|
||||
@ -261,48 +260,48 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
}
|
||||
```
|
||||
|
||||
| Політика | Поведінка |
|
||||
| Політика | Поведінка |
|
||||
| ------------- | ------------------------------------------------------------ |
|
||||
| `"open"` | Групи обходять allowlist; шлюзування за згадкою все ще застосовується. |
|
||||
| `"disabled"` | Повністю блокувати всі групові повідомлення. |
|
||||
| `"allowlist"` | Дозволяти лише групи/кімнати, які відповідають налаштованому allowlist. |
|
||||
| `"open"` | Групи обходять списки дозволених; шлюзування за згадками все ще застосовується. |
|
||||
| `"disabled"` | Повністю блокувати всі групові повідомлення. |
|
||||
| `"allowlist"` | Дозволяти лише групи/кімнати, які відповідають налаштованому списку дозволених. |
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Нотатки для кожного каналу">
|
||||
- `groupPolicy` відокремлена від шлюзування за згадкою (яке потребує @згадок).
|
||||
<Accordion title="Нотатки для окремих каналів">
|
||||
- `groupPolicy` окремий від шлюзування за згадками (яке вимагає @згадок).
|
||||
- WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo: використовуйте `groupAllowFrom` (резервний варіант: явний `allowFrom`).
|
||||
- Signal: `groupAllowFrom` може відповідати або вхідному ідентифікатору групи Signal, або телефону/UUID відправника.
|
||||
- Схвалення сполучення DM (записи сховища `*-allowFrom`) застосовуються лише до доступу DM; авторизація відправника в групі лишається явно прив’язаною до групових allowlist.
|
||||
- Discord: allowlist використовує `channels.discord.guilds.<id>.channels`.
|
||||
- Slack: allowlist використовує `channels.slack.channels`.
|
||||
- Matrix: allowlist використовує `channels.matrix.groups`. Надавайте перевагу ідентифікаторам кімнат або псевдонімам; пошук за назвою приєднаної кімнати виконується за принципом найкращої спроби, а нерозв’язані назви ігноруються під час виконання. Використовуйте `channels.matrix.groupAllowFrom`, щоб обмежити відправників; allowlist `users` для окремих кімнат також підтримуються.
|
||||
- Групові DM контролюються окремо (`channels.discord.dm.*`, `channels.slack.dm.*`).
|
||||
- Allowlist Telegram може відповідати ідентифікаторам користувачів (`"123456789"`, `"telegram:123456789"`, `"tg:123456789"`) або іменам користувачів (`"@alice"` чи `"alice"`); префікси нечутливі до регістру.
|
||||
- Типово використовується `groupPolicy: "allowlist"`; якщо ваш груповий allowlist порожній, групові повідомлення блокуються.
|
||||
- Безпека під час виконання: коли блок провайдера повністю відсутній (`channels.<provider>` відсутній), політика груп повертається до режиму fail-closed (зазвичай `allowlist`) замість успадкування `channels.defaults.groupPolicy`.
|
||||
- Signal: `groupAllowFrom` може збігатися або з вхідним ідентифікатором групи Signal, або з телефоном/UUID відправника.
|
||||
- Схвалення сполучення DM (записи сховища `*-allowFrom`) застосовуються лише до доступу DM; авторизація відправників у групах залишається явно прив’язаною до групових списків дозволених.
|
||||
- Discord: список дозволених використовує `channels.discord.guilds.<id>.channels`.
|
||||
- Slack: список дозволених використовує `channels.slack.channels`.
|
||||
- Matrix: список дозволених використовує `channels.matrix.groups`. Надавайте перевагу ідентифікаторам кімнат або псевдонімам; пошук назв приєднаних кімнат виконується за принципом best-effort, а нерозв’язані назви ігноруються під час виконання. Використовуйте `channels.matrix.groupAllowFrom`, щоб обмежити відправників; списки дозволених `users` для окремих кімнат також підтримуються.
|
||||
- Групові DM керуються окремо (`channels.discord.dm.*`, `channels.slack.dm.*`).
|
||||
- Список дозволених Telegram може збігатися з ідентифікаторами користувачів (`"123456789"`, `"telegram:123456789"`, `"tg:123456789"`) або іменами користувачів (`"@alice"` чи `"alice"`); префікси нечутливі до регістру.
|
||||
- За замовчуванням використовується `groupPolicy: "allowlist"`; якщо ваш груповий список дозволених порожній, групові повідомлення блокуються.
|
||||
- Безпека під час виконання: коли блок провайдера повністю відсутній (`channels.<provider>` відсутній), політика груп повертається до fail-closed режиму (зазвичай `allowlist`) замість успадкування `channels.defaults.groupPolicy`.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
Швидка ментальна модель (порядок оцінювання для групових повідомлень):
|
||||
Коротка ментальна модель (порядок оцінювання для групових повідомлень):
|
||||
|
||||
<Steps>
|
||||
<Step title="groupPolicy">
|
||||
`groupPolicy` (open/disabled/allowlist).
|
||||
`groupPolicy` (відкрито/вимкнено/список дозволених).
|
||||
</Step>
|
||||
<Step title="Списки дозволених груп">
|
||||
Списки дозволених груп (`*.groups`, `*.groupAllowFrom`, список дозволених для конкретного каналу).
|
||||
</Step>
|
||||
<Step title="Фільтрація за згадкою">
|
||||
Фільтрація за згадкою (`requireMention`, `/activation`).
|
||||
<Step title="Шлюз згадок">
|
||||
Шлюз згадок (`requireMention`, `/activation`).
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Фільтрація за згадкою (типово)
|
||||
## Шлюз згадок (типово)
|
||||
|
||||
Групові повідомлення потребують згадки, якщо це не перевизначено для групи. Типові значення зберігаються для кожної підсистеми в `*.groups."*"`.
|
||||
Групові повідомлення потребують згадки, якщо це не перевизначено для окремої групи. Типові значення задаються для кожної підсистеми в `*.groups."*"`.
|
||||
|
||||
Відповідь на повідомлення бота вважається неявною згадкою, коли канал підтримує метадані відповіді. Цитування повідомлення бота також може вважатися неявною згадкою в каналах, які надають метадані цитування. Поточні вбудовані випадки включають Telegram, WhatsApp, Slack, Discord, Microsoft Teams і ZaloUser.
|
||||
Відповідь на повідомлення бота рахується як неявна згадка, коли канал підтримує метадані відповіді. Цитування повідомлення бота також може рахуватися як неявна згадка на каналах, які надають метадані цитати. Поточні вбудовані випадки включають Telegram, WhatsApp, Slack, Discord, Microsoft Teams і ZaloUser.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -341,40 +340,40 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
```
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Примітки щодо фільтрації за згадкою">
|
||||
- `mentionPatterns` — це безпечні regex-шаблони без урахування регістру; недійсні шаблони й небезпечні форми з вкладеним повторенням ігноруються.
|
||||
<Accordion title="Нотатки щодо шлюзу згадок">
|
||||
- `mentionPatterns` — це безпечні regex-шаблони без урахування регістру; недійсні шаблони та небезпечні форми вкладеного повторення ігноруються.
|
||||
- Поверхні, які надають явні згадки, усе одно проходять; шаблони є резервним варіантом.
|
||||
- Перевизначення для окремого агента: `agents.list[].groupChat.mentionPatterns` (корисно, коли кілька агентів спільно використовують групу).
|
||||
- Фільтрація за згадкою застосовується лише тоді, коли виявлення згадок можливе (налаштовано нативні згадки або `mentionPatterns`).
|
||||
- Додавання групи чи відправника до списку дозволених не вимикає фільтрацію за згадкою; встановіть для цієї групи `requireMention` у `false`, коли всі повідомлення мають запускати відповідь.
|
||||
- Контекст підказки групового чату передає визначену інструкцію тихої відповіді на кожному ході; файли робочого простору не повинні дублювати механіку `NO_REPLY`.
|
||||
- Групи, де дозволені тихі відповіді, трактують чисті порожні або лише міркувальні ходи моделі як тишу, еквівалентну `NO_REPLY`. Прямі чати роблять те саме лише тоді, коли прямі тихі відповіді явно дозволені; інакше порожні відповіді залишаються невдалими ходами агента.
|
||||
- Типові значення Discord зберігаються в `channels.discord.guilds."*"` (можна перевизначити для окремої гільдії/каналу).
|
||||
- Контекст історії групи однаково обгортається в усіх каналах і є **лише відкладеним** (повідомлення, пропущені через фільтрацію за згадкою); використовуйте `messages.groupChat.historyLimit` для глобального типового значення та `channels.<channel>.historyLimit` (або `channels.<channel>.accounts.*.historyLimit`) для перевизначень. Встановіть `0`, щоб вимкнути.
|
||||
- Шлюз згадок застосовується лише тоді, коли виявлення згадок можливе (налаштовано нативні згадки або `mentionPatterns`).
|
||||
- Додавання групи або відправника до списку дозволених не вимикає шлюз згадок; встановіть для цієї групи `requireMention` у `false`, коли всі повідомлення мають запускати обробку.
|
||||
- Контекст підказки групового чату переносить вирішену інструкцію тихої відповіді на кожному ході; файли робочого простору не повинні дублювати механіку `NO_REPLY`.
|
||||
- Групи, де дозволені тихі відповіді, трактують чисті порожні ходи моделі або ходи лише з міркуванням як тихі, еквівалентні `NO_REPLY`. Прямі чати роблять те саме лише тоді, коли прямі тихі відповіді явно дозволені; інакше порожні відповіді залишаються невдалими ходами агента.
|
||||
- Типові значення Discord задаються в `channels.discord.guilds."*"` (можна перевизначати для окремої гільдії/каналу).
|
||||
- Контекст історії групи обгортається однаково для всіх каналів і є **лише для очікуваних** повідомлень (повідомлення, пропущені через шлюз згадок); використовуйте `messages.groupChat.historyLimit` для глобального типового значення та `channels.<channel>.historyLimit` (або `channels.<channel>.accounts.*.historyLimit`) для перевизначень. Установіть `0`, щоб вимкнути.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Обмеження інструментів групи/каналу (необов’язково)
|
||||
|
||||
Деякі конфігурації каналів підтримують обмеження, які інструменти доступні **всередині конкретної групи/кімнати/каналу**.
|
||||
Деякі конфігурації каналів підтримують обмеження того, які інструменти доступні **всередині конкретної групи/кімнати/каналу**.
|
||||
|
||||
- `tools`: дозволити/заборонити інструменти для всієї групи.
|
||||
- `toolsBySender`: перевизначення для окремих відправників у межах групи. Використовуйте явні префікси ключів: `id:<senderId>`, `e164:<phone>`, `username:<handle>`, `name:<displayName>` і wildcard `"*"`. Застарілі ключі без префікса все ще приймаються й зіставляються лише як `id:`.
|
||||
- `toolsBySender`: перевизначення для окремих відправників у групі. Використовуйте явні префікси ключів: `id:<senderId>`, `e164:<phone>`, `username:<handle>`, `name:<displayName>` і wildcard `"*"`. Застарілі ключі без префікса все ще приймаються та зіставляються лише як `id:`.
|
||||
|
||||
Порядок розв’язання (найконкретніше перемагає):
|
||||
Порядок вирішення (найбільш конкретний перемагає):
|
||||
|
||||
<Steps>
|
||||
<Step title="Group toolsBySender">
|
||||
Збіг `toolsBySender` для групи/каналу.
|
||||
Збіг `toolsBySender` групи/каналу.
|
||||
</Step>
|
||||
<Step title="Інструменти групи">
|
||||
<Step title="Group tools">
|
||||
`tools` групи/каналу.
|
||||
</Step>
|
||||
<Step title="Типовий toolsBySender">
|
||||
<Step title="Default toolsBySender">
|
||||
Збіг типового (`"*"`) `toolsBySender`.
|
||||
</Step>
|
||||
<Step title="Типові інструменти">
|
||||
<Step title="Default tools">
|
||||
Типові (`"*"`) `tools`.
|
||||
</Step>
|
||||
</Steps>
|
||||
@ -400,18 +399,18 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
```
|
||||
|
||||
<Note>
|
||||
Обмеження інструментів групи/каналу застосовуються на додачу до глобальної політики інструментів або політики інструментів агента (заборона все одно перемагає). Деякі канали використовують іншу вкладеність для кімнат/каналів (наприклад, Discord `guilds.*.channels.*`, Slack `channels.*`, Microsoft Teams `teams.*.channels.*`).
|
||||
Обмеження інструментів групи/каналу застосовуються на додачу до глобальної/агентської політики інструментів (заборона все одно перемагає). Деякі канали використовують іншу вкладеність для кімнат/каналів (наприклад, Discord `guilds.*.channels.*`, Slack `channels.*`, Microsoft Teams `teams.*.channels.*`).
|
||||
</Note>
|
||||
|
||||
## Списки дозволених груп
|
||||
|
||||
Коли налаштовано `channels.whatsapp.groups`, `channels.telegram.groups` або `channels.imessage.groups`, ключі діють як список дозволених груп. Використовуйте `"*"`, щоб дозволити всі групи, водночас задаючи типову поведінку щодо згадок.
|
||||
Коли налаштовано `channels.whatsapp.groups`, `channels.telegram.groups` або `channels.imessage.groups`, ключі діють як список дозволених груп. Використовуйте `"*"`, щоб дозволити всі групи, водночас задаючи типову поведінку згадок.
|
||||
|
||||
<Warning>
|
||||
Поширена плутанина: схвалення створення пари для DM — це не те саме, що авторизація групи. Для каналів, які підтримують створення пари для DM, сховище пар розблоковує лише DM. Групові команди все ще потребують явної авторизації відправника групи зі списків дозволених у конфігурації, як-от `groupAllowFrom`, або задокументованого резервного варіанта конфігурації для цього каналу.
|
||||
Поширена плутанина: схвалення парування DM — це не те саме, що авторизація групи. Для каналів, які підтримують парування DM, сховище парування розблоковує лише DM. Групові команди все одно потребують явної авторизації відправника групи зі списків дозволених у конфігурації, таких як `groupAllowFrom`, або документованого резервного варіанта конфігурації для цього каналу.
|
||||
</Warning>
|
||||
|
||||
Поширені наміри (скопіюйте/вставте):
|
||||
Поширені наміри (копіювати/вставити):
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Вимкнути всі групові відповіді">
|
||||
@ -468,25 +467,25 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
- `/activation mention`
|
||||
- `/activation always`
|
||||
|
||||
Власник визначається за `channels.whatsapp.allowFrom` (або за власним E.164 бота, якщо не задано). Надішліть команду як окреме повідомлення. Інші поверхні наразі ігнорують `/activation`.
|
||||
Власник визначається через `channels.whatsapp.allowFrom` (або власний E.164 бота, якщо не задано). Надішліть команду окремим повідомленням. Інші поверхні наразі ігнорують `/activation`.
|
||||
|
||||
## Поля контексту
|
||||
|
||||
Вхідні групові payload задають:
|
||||
Вхідні payload групи задають:
|
||||
|
||||
- `ChatType=group`
|
||||
- `GroupSubject` (якщо відомо)
|
||||
- `GroupMembers` (якщо відомо)
|
||||
- `WasMentioned` (результат фільтрації за згадкою)
|
||||
- Теми форуму Telegram також містять `MessageThreadId` та `IsForum`.
|
||||
- `WasMentioned` (результат шлюзу згадок)
|
||||
- Теми форумів Telegram також включають `MessageThreadId` і `IsForum`.
|
||||
|
||||
Примітки для конкретних каналів:
|
||||
Нотатки для конкретних каналів:
|
||||
|
||||
- BlueBubbles може необов’язково доповнювати безіменних учасників груп macOS з локальної бази даних Contacts перед заповненням `GroupMembers`. Це вимкнено за замовчуванням і запускається лише після проходження звичайної групової фільтрації.
|
||||
- BlueBubbles може додатково збагачувати безіменних учасників групи macOS із локальної бази даних Contacts перед заповненням `GroupMembers`. Це вимкнено за замовчуванням і виконується лише після проходження звичайного шлюзу групи.
|
||||
|
||||
Системна підказка агента містить груповий вступ на першому ході нової групової сесії. Вона нагадує моделі відповідати як людина, уникати Markdown-таблиць, мінімізувати порожні рядки й дотримуватися звичайних інтервалів у чаті, а також не вводити буквальні послідовності `\n`. Назви груп і мітки учасників, отримані з каналу, відображаються як огороджені недовірені метадані, а не як вбудовані системні інструкції.
|
||||
Системна підказка агента включає груповий вступ на першому ході нового групового сеансу. Вона нагадує моделі відповідати як людина, уникати Markdown-таблиць, мінімізувати порожні рядки й дотримуватися звичайних інтервалів чату, а також не вводити буквальні послідовності `\n`. Назви груп і мітки учасників, отримані з каналів, відображаються як відгороджені недовірені метадані, а не як вбудовані системні інструкції.
|
||||
|
||||
## Особливості iMessage
|
||||
## Специфіка iMessage
|
||||
|
||||
- Надавайте перевагу `chat_id:<id>` під час маршрутизації або додавання до списку дозволених.
|
||||
- Список чатів: `imsg chats --limit 20`.
|
||||
@ -494,15 +493,15 @@ Gateway гаряче перезавантажує конфігурацію `mess
|
||||
|
||||
## Системні підказки WhatsApp
|
||||
|
||||
Див. [WhatsApp](/uk/channels/whatsapp#system-prompts) для канонічних правил системних підказок WhatsApp, включно з розв’язанням групових і прямих підказок, поведінкою wildcard і семантикою перевизначень облікового запису.
|
||||
Див. [WhatsApp](/uk/channels/whatsapp#system-prompts) для канонічних правил системних підказок WhatsApp, включно з вирішенням групових і прямих підказок, поведінкою wildcard і семантикою перевизначення облікового запису.
|
||||
|
||||
## Особливості WhatsApp
|
||||
## Специфіка WhatsApp
|
||||
|
||||
Див. [Групові повідомлення](/uk/channels/group-messages) щодо поведінки лише для WhatsApp (вставлення історії, деталі обробки згадок).
|
||||
Див. [Групові повідомлення](/uk/channels/group-messages) для поведінки лише WhatsApp (вставка історії, деталі обробки згадок).
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Групи розсилки](/uk/channels/broadcast-groups)
|
||||
- [Групи трансляцій](/uk/channels/broadcast-groups)
|
||||
- [Маршрутизація каналів](/uk/channels/channel-routing)
|
||||
- [Групові повідомлення](/uk/channels/group-messages)
|
||||
- [Створення пари](/uk/channels/pairing)
|
||||
- [Парування](/uk/channels/pairing)
|
||||
|
||||
@ -1,20 +1,20 @@
|
||||
---
|
||||
read_when:
|
||||
- Додавання або змінення міграцій doctor
|
||||
- Впровадження несумісних змін конфігурації
|
||||
- Додавання або зміна міграцій doctor
|
||||
- Внесення несумісних змін конфігурації
|
||||
sidebarTitle: Doctor
|
||||
summary: 'Команда doctor: перевірки справності, міграції конфігурації та кроки відновлення'
|
||||
title: Діагностика
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T18:57:45Z"
|
||||
generated_at: "2026-05-03T09:37:06Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 504cf06e8457315eb1df4970a877b88fdc2e32f34974ce789875373e9e030234
|
||||
source_hash: 20b2cb3c3cd88e01050cb285a08a020603642439bd35668b7414360801fc03ff
|
||||
source_path: gateway/doctor.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
`openclaw doctor` — це інструмент відновлення + міграції для OpenClaw. Він виправляє застарілі конфігурації/стан, перевіряє працездатність і надає дієві кроки для відновлення.
|
||||
`openclaw doctor` — це інструмент відновлення та міграції для OpenClaw. Він виправляє застарілі конфігурацію/стан, перевіряє справність і надає дієві кроки для відновлення.
|
||||
|
||||
## Швидкий старт
|
||||
|
||||
@ -22,7 +22,7 @@ x-i18n:
|
||||
openclaw doctor
|
||||
```
|
||||
|
||||
### Безголові режими та режими автоматизації
|
||||
### Режими без інтерфейсу та автоматизації
|
||||
|
||||
<Tabs>
|
||||
<Tab title="--yes">
|
||||
@ -30,7 +30,7 @@ openclaw doctor
|
||||
openclaw doctor --yes
|
||||
```
|
||||
|
||||
Приймати стандартні значення без запитів (включно з кроками відновлення перезапуску/служби/пісочниці, коли застосовно).
|
||||
Прийняти значення за замовчуванням без запитів (зокрема кроки перезапуску/служби/відновлення sandbox, коли застосовно).
|
||||
|
||||
</Tab>
|
||||
<Tab title="--repair">
|
||||
@ -38,7 +38,7 @@ openclaw doctor
|
||||
openclaw doctor --repair
|
||||
```
|
||||
|
||||
Застосувати рекомендовані виправлення без запитів (виправлення + перезапуски, де це безпечно).
|
||||
Застосувати рекомендовані відновлення без запитів (відновлення + перезапуски, коли це безпечно).
|
||||
|
||||
</Tab>
|
||||
<Tab title="--repair --force">
|
||||
@ -46,7 +46,7 @@ openclaw doctor
|
||||
openclaw doctor --repair --force
|
||||
```
|
||||
|
||||
Також застосувати агресивні виправлення (перезаписує користувацькі конфігурації супервізора).
|
||||
Застосувати також агресивні відновлення (перезаписує користувацькі конфіги supervisor).
|
||||
|
||||
</Tab>
|
||||
<Tab title="--non-interactive">
|
||||
@ -54,7 +54,7 @@ openclaw doctor
|
||||
openclaw doctor --non-interactive
|
||||
```
|
||||
|
||||
Запустити без запитів і застосувати лише безпечні міграції (нормалізація конфігурації + переміщення стану на диску). Пропускає дії перезапуску/служби/пісочниці, які потребують підтвердження людиною. Міграції застарілого стану запускаються автоматично після виявлення.
|
||||
Запустити без запитів і застосувати лише безпечні міграції (нормалізацію конфігурації + перенесення стану на диску). Пропускає дії перезапуску/служби/sandbox, які потребують підтвердження людини. Міграції застарілого стану запускаються автоматично, коли їх виявлено.
|
||||
|
||||
</Tab>
|
||||
<Tab title="--deep">
|
||||
@ -62,124 +62,124 @@ openclaw doctor
|
||||
openclaw doctor --deep
|
||||
```
|
||||
|
||||
Просканувати системні служби на додаткові встановлення gateway (launchd/systemd/schtasks).
|
||||
Просканувати системні служби на наявність додаткових інсталяцій Gateway (launchd/systemd/schtasks).
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Якщо ви хочете переглянути зміни перед записом, спершу відкрийте файл конфігурації:
|
||||
Якщо ви хочете переглянути зміни перед записом, спочатку відкрийте файл конфігурації:
|
||||
|
||||
```bash
|
||||
cat ~/.openclaw/openclaw.json
|
||||
```
|
||||
|
||||
## Що він робить (зведення)
|
||||
## Що він робить (коротко)
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Health, UI, and updates">
|
||||
- Необов’язкове попереднє оновлення для git-встановлень (лише інтерактивно).
|
||||
- Перевірка актуальності протоколу UI (перебудовує Control UI, коли схема протоколу новіша).
|
||||
- Перевірка працездатності + запит на перезапуск.
|
||||
- Зведення стану Skills (доступні/відсутні/заблоковані) і стан plugin.
|
||||
<Accordion title="Справність, інтерфейс і оновлення">
|
||||
- Необов’язкове попереднє оновлення для git-інсталяцій (лише інтерактивно).
|
||||
- Перевірка актуальності протоколу інтерфейсу (перезбирає Control UI, коли схема протоколу новіша).
|
||||
- Перевірка справності + запит на перезапуск.
|
||||
- Зведення стану Skills (придатні/відсутні/заблоковані) і стан Plugin.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Config and migrations">
|
||||
<Accordion title="Конфігурація та міграції">
|
||||
- Нормалізація конфігурації для застарілих значень.
|
||||
- Міграція конфігурації Talk із застарілих плоских полів `talk.*` у `talk.provider` + `talk.providers.<provider>`.
|
||||
- Перевірки міграції браузера для застарілих конфігурацій розширення Chrome і готовності Chrome MCP.
|
||||
- Перевірки міграції браузера для застарілих конфігів Chrome extension і готовності Chrome MCP.
|
||||
- Попередження про перевизначення провайдера OpenCode (`models.providers.opencode` / `models.providers.opencode-go`).
|
||||
- Попередження про затінення OAuth Codex (`models.providers.openai-codex`).
|
||||
- Перевірка передумов TLS OAuth для профілів OpenAI Codex OAuth.
|
||||
- Попередження щодо списку дозволених plugin/інструментів, коли `plugins.allow` є обмежувальним, але політика інструментів усе ще запитує wildcard або інструменти, що належать plugin.
|
||||
- Міграція застарілого стану на диску (сесії/каталог агента/автентифікація WhatsApp).
|
||||
- Міграція застарілих ключів контракту маніфесту plugin (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`).
|
||||
- Міграція застарілого сховища cron (`jobId`, `schedule.cron`, поля доставки/payload верхнього рівня, payload `provider`, прості резервні webhook-завдання `notify: true`).
|
||||
- Перевірка передумов OAuth TLS для профілів OpenAI Codex OAuth.
|
||||
- Попередження про allowlist Plugin/інструментів, коли `plugins.allow` обмежувальний, але політика інструментів усе ще запитує wildcard або інструменти, що належать Plugin.
|
||||
- Міграція застарілого стану на диску (sessions/agent dir/WhatsApp auth).
|
||||
- Міграція застарілих ключів контракту маніфесту Plugin (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`).
|
||||
- Міграція застарілого сховища Cron (`jobId`, `schedule.cron`, поля delivery/payload верхнього рівня, payload `provider`, прості резервні завдання Webhook `notify: true`).
|
||||
- Міграція застарілої runtime-policy агента до `agents.defaults.agentRuntime` і `agents.list[].agentRuntime`.
|
||||
- Очищення застарілої конфігурації plugin, коли plugins увімкнені; коли `plugins.enabled=false`, застарілі посилання на plugin вважаються інертною конфігурацією стримування та зберігаються.
|
||||
- Очищення застарілої конфігурації Plugin, коли plugins увімкнено; коли `plugins.enabled=false`, застарілі посилання на Plugin вважаються інертною конфігурацією ізоляції та зберігаються.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="State and integrity">
|
||||
- Перевірка lock-файлів сесій і очищення застарілих lock-файлів.
|
||||
- Відновлення транскриптів сесій для дубльованих гілок переписування промптів, створених у зачеплених збірках 2026.4.24.
|
||||
- Виявлення tombstone для відновлення після перезапуску застряглого subagent, з підтримкою `--fix` для очищення застарілих прапорців перерваного відновлення, щоб запуск не продовжував вважати дочірній процес перерваним під час перезапуску.
|
||||
- Перевірки цілісності стану та дозволів (сесії, транскрипти, каталог стану).
|
||||
<Accordion title="Стан і цілісність">
|
||||
- Перевірка lock-файла сесії та очищення застарілих lock.
|
||||
- Відновлення transcript сесії для дубльованих гілок prompt-rewrite, створених ураженими збірками 2026.4.24.
|
||||
- Виявлення tombstone для відновлення після перезапуску застряглого subagent, з підтримкою `--fix` для очищення застарілих прапорців aborted recovery, щоб запуск не продовжував трактувати дочірній процес як restart-aborted.
|
||||
- Перевірки цілісності стану та дозволів (sessions, transcripts, state dir).
|
||||
- Перевірки дозволів файлу конфігурації (chmod 600) під час локального запуску.
|
||||
- Стан автентифікації моделі: перевіряє завершення строку дії OAuth, може оновлювати токени, строк дії яких спливає, і повідомляє про стани cooldown/disabled auth-profile.
|
||||
- Виявлення додаткового каталогу робочої області (`~/openclaw`).
|
||||
- Справність автентифікації моделей: перевіряє завершення строку OAuth, може оновлювати токени, строк дії яких спливає, і повідомляє про стани cooldown/disabled auth-profile.
|
||||
- Виявлення додаткової директорії workspace (`~/openclaw`).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Gateway, services, and supervisors">
|
||||
- Відновлення образу пісочниці, коли sandboxing увімкнено.
|
||||
- Міграція застарілої служби та виявлення додаткових gateway.
|
||||
<Accordion title="Gateway, служби та supervisor">
|
||||
- Відновлення sandbox image, коли sandboxing увімкнено.
|
||||
- Міграція застарілих служб і виявлення додаткового Gateway.
|
||||
- Міграція застарілого стану каналу Matrix (у режимі `--fix` / `--repair`).
|
||||
- Перевірки runtime Gateway (службу встановлено, але вона не запущена; кешована мітка launchd).
|
||||
- Попередження про стан каналів (перевіряються з запущеного gateway).
|
||||
- Аудит конфігурації супервізора (launchd/systemd/schtasks) з необов’язковим відновленням.
|
||||
- Очищення середовища вбудованого проксі для служб gateway, які захопили значення shell `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` під час встановлення або оновлення.
|
||||
- Перевірки найкращих практик runtime Gateway (Node проти Bun, шляхи менеджера версій).
|
||||
- Діагностика конфлікту порту Gateway (типово `18789`).
|
||||
- Runtime-перевірки Gateway (службу встановлено, але не запущено; кешована launchd label).
|
||||
- Попередження про стан каналів (перевіряються із запущеного Gateway).
|
||||
- Аудит конфігурації supervisor (launchd/systemd/schtasks) з необов’язковим відновленням.
|
||||
- Очищення середовища вбудованого proxy для служб Gateway, які захопили значення shell `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` під час інсталяції або оновлення.
|
||||
- Перевірки найкращих практик runtime Gateway (Node проти Bun, шляхи version-manager).
|
||||
- Діагностика конфліктів порту Gateway (типово `18789`).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Auth, security, and pairing">
|
||||
<Accordion title="Автентифікація, безпека та сполучення">
|
||||
- Попередження безпеки для відкритих політик DM.
|
||||
- Перевірки автентифікації Gateway для режиму локального токена (пропонує генерацію токена, коли джерела токена немає; не перезаписує конфігурації SecretRef токена).
|
||||
- Виявлення проблем зі спарюванням пристроїв (очікувані перші запити на спарювання, очікувані оновлення ролі/області, застарілий drift локального кешу device-token і drift автентифікації paired-record).
|
||||
- Перевірки автентифікації Gateway для режиму локального токена (пропонує генерацію токена, коли джерела токена немає; не перезаписує конфіги токена SecretRef).
|
||||
- Виявлення проблем зі сполученням пристрою (очікувані перші запити на сполучення, очікувані підвищення ролі/області, дрейф застарілого локального кешу device-token і дрейф автентифікації paired-record).
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Workspace and shell">
|
||||
<Accordion title="Workspace і shell">
|
||||
- Перевірка systemd linger у Linux.
|
||||
- Перевірка розміру bootstrap-файлу робочої області (попередження про обрізання/наближення до ліміту для контекстних файлів).
|
||||
- Перевірка готовності Skills для агента за замовчуванням; повідомляє дозволені skills з відсутніми bin, env, config або вимогами ОС, а `--fix` може вимкнути недоступні skills у `skills.entries`.
|
||||
- Перевірка стану автодоповнення shell і автоматичне встановлення/оновлення.
|
||||
- Перевірка готовності embedding-провайдера пошуку пам’яті (локальна модель, ключ віддаленого API або бінарний файл QMD).
|
||||
- Перевірки встановлення з джерел (невідповідність робочої області pnpm, відсутні UI-ресурси, відсутній бінарний файл tsx).
|
||||
- Записує оновлену конфігурацію + метадані wizard.
|
||||
- Перевірка розміру bootstrap-файла workspace (попередження про обрізання/наближення до ліміту для файлів контексту).
|
||||
- Перевірка готовності Skills для агента за замовчуванням; повідомляє про дозволені skills з відсутніми bins, env, config або вимогами ОС, а `--fix` може вимкнути недоступні skills у `skills.entries`.
|
||||
- Перевірка стану shell completion і автоматична інсталяція/оновлення.
|
||||
- Перевірка готовності провайдера embeddings для пошуку пам’яті (локальна модель, ключ віддаленого API або QMD binary).
|
||||
- Перевірки source install (невідповідність pnpm workspace, відсутні UI assets, відсутній tsx binary).
|
||||
- Записує оновлену конфігурацію + metadata wizard.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Зворотне заповнення та скидання Dreams UI
|
||||
## Зворотне заповнення та скидання UI Dreams
|
||||
|
||||
Сцена Dreams у Control UI містить дії **Backfill**, **Reset** і **Clear Grounded** для workflow grounded dreaming. Ці дії використовують RPC-методи в стилі gateway doctor, але вони **не** є частиною CLI-відновлення/міграції `openclaw doctor`.
|
||||
Сцена Dreams у Control UI містить дії **Зворотне заповнення**, **Скидання** та **Очистити обґрунтоване** для робочого процесу обґрунтованого Dreaming. Ці дії використовують RPC-методи Gateway у стилі doctor, але вони **не** є частиною відновлення/міграції CLI `openclaw doctor`.
|
||||
|
||||
Що вони роблять:
|
||||
|
||||
- **Backfill** сканує історичні файли `memory/YYYY-MM-DD.md` в активній робочій області, запускає grounded REM diary pass і записує оборотні записи зворотного заповнення в `DREAMS.md`.
|
||||
- **Reset** видаляє лише ці позначені diary-записи зворотного заповнення з `DREAMS.md`.
|
||||
- **Clear Grounded** видаляє лише підготовлені короткострокові записи grounded-only, які походять з історичного replay і ще не накопичили live recall або daily support.
|
||||
- **Зворотне заповнення** сканує історичні файли `memory/YYYY-MM-DD.md` в активному workspace, запускає grounded REM diary pass і записує оборотні backfill entries у `DREAMS.md`.
|
||||
- **Скидання** видаляє з `DREAMS.md` лише ці позначені backfill diary entries.
|
||||
- **Очистити обґрунтоване** видаляє лише підготовлені grounded-only short-term entries, що надійшли з історичного replay і ще не накопичили live recall або daily support.
|
||||
|
||||
Чого вони самі по собі **не** роблять:
|
||||
Чого вони самі **не** роблять:
|
||||
|
||||
- вони не редагують `MEMORY.md`
|
||||
- вони не запускають повні міграції doctor
|
||||
- вони автоматично не розміщують grounded-кандидатів у live short-term promotion store, якщо ви явно спершу не запустите staged CLI path
|
||||
- вони не додають автоматично grounded candidates до live short-term promotion store, якщо ви спочатку явно не запустите staged CLI path
|
||||
|
||||
Якщо ви хочете, щоб grounded historical replay впливав на звичайну deep promotion lane, натомість використайте CLI-flow:
|
||||
Якщо ви хочете, щоб grounded historical replay впливав на звичайну deep promotion lane, натомість використовуйте CLI flow:
|
||||
|
||||
```bash
|
||||
openclaw memory rem-backfill --path ./memory --stage-short-term
|
||||
```
|
||||
|
||||
Це розміщує grounded durable candidates у short-term dreaming store, залишаючи `DREAMS.md` поверхнею для перегляду.
|
||||
Це додає grounded durable candidates до short-term dreaming store, водночас залишаючи `DREAMS.md` як поверхню для перегляду.
|
||||
|
||||
## Детальна поведінка та обґрунтування
|
||||
## Докладна поведінка та обґрунтування
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="0. Optional update (git installs)">
|
||||
Якщо це git checkout і doctor запускається інтерактивно, він пропонує оновитися (fetch/rebase/build) перед запуском doctor.
|
||||
<Accordion title="0. Необов’язкове оновлення (git-інсталяції)">
|
||||
Якщо це git checkout і doctor працює інтерактивно, він пропонує оновитися (fetch/rebase/build) перед запуском doctor.
|
||||
</Accordion>
|
||||
<Accordion title="1. Config normalization">
|
||||
Якщо конфігурація містить застарілі форми значень (наприклад, `messages.ackReaction` без перевизначення для конкретного каналу), doctor нормалізує їх до поточної схеми.
|
||||
<Accordion title="1. Нормалізація конфігурації">
|
||||
Якщо конфігурація містить застарілі форми значень (наприклад, `messages.ackReaction` без channel-specific override), doctor нормалізує їх у поточну схему.
|
||||
|
||||
Це включає застарілі плоскі поля Talk. Поточна публічна конфігурація Talk — це `talk.provider` + `talk.providers.<provider>`. Doctor переписує старі форми `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` / `talk.apiKey` у мапу провайдерів.
|
||||
Це включає застарілі плоскі поля Talk. Поточна публічна конфігурація Talk — це `talk.provider` + `talk.providers.<provider>`. Doctor переписує старі форми `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` / `talk.apiKey` у provider map.
|
||||
|
||||
Doctor також попереджає, коли `plugins.allow` не порожній і політика інструментів використовує
|
||||
wildcard або записи інструментів, що належать plugin. `tools.allow: ["*"]` відповідає лише інструментам
|
||||
із plugins, які фактично завантажуються; це не обходить ексклюзивний список дозволених plugin.
|
||||
wildcard або записи інструментів, що належать Plugin. `tools.allow: ["*"]` відповідає лише інструментам
|
||||
із plugins, які фактично завантажуються; він не обходить ексклюзивний allowlist Plugin.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="2. Legacy config key migrations">
|
||||
Коли конфігурація містить застарілі ключі, інші команди відмовляються запускатися й просять вас запустити `openclaw doctor`.
|
||||
<Accordion title="2. Міграції застарілих ключів конфігурації">
|
||||
Коли конфігурація містить застарілі ключі, інші команди відмовляються запускатися й просять вас виконати `openclaw doctor`.
|
||||
|
||||
Doctor:
|
||||
|
||||
@ -187,7 +187,7 @@ openclaw memory rem-backfill --path ./memory --stage-short-term
|
||||
- Покаже застосовану міграцію.
|
||||
- Перепише `~/.openclaw/openclaw.json` з оновленою схемою.
|
||||
|
||||
Gateway також автоматично запускає міграції doctor під час запуску, коли виявляє застарілий формат конфігурації, тому застарілі конфігурації відновлюються без ручного втручання. Міграції сховища Cron-завдань обробляє `openclaw doctor --fix`.
|
||||
Gateway також автоматично запускає міграції doctor під час запуску, коли виявляє застарілий формат конфігурації, тож застарілі конфіги відновлюються без ручного втручання. Міграції сховища завдань Cron обробляються командою `openclaw doctor --fix`.
|
||||
|
||||
Поточні міграції:
|
||||
|
||||
@ -195,8 +195,9 @@ openclaw memory rem-backfill --path ./memory --stage-short-term
|
||||
- `routing.groupChat.requireMention` → `channels.whatsapp/telegram/imessage.groups."*".requireMention`
|
||||
- `routing.groupChat.historyLimit` → `messages.groupChat.historyLimit`
|
||||
- `routing.groupChat.mentionPatterns` → `messages.groupChat.mentionPatterns`
|
||||
- конфігурації налаштованих каналів без видимої політики відповіді → `messages.groupChat.visibleReplies: "message_tool"`
|
||||
- `routing.queue` → `messages.queue`
|
||||
- `routing.bindings` → верхньорівневий `bindings`
|
||||
- `routing.bindings` → верхньорівневі `bindings`
|
||||
- `routing.agents`/`routing.defaultAgentId` → `agents.list` + `agents.list[].default`
|
||||
- застарілі `talk.voiceId`/`talk.voiceAliases`/`talk.modelId`/`talk.outputFormat`/`talk.apiKey` → `talk.provider` + `talk.providers.<provider>`
|
||||
- `routing.agentToAgent` → `tools.agentToAgent`
|
||||
@ -212,7 +213,7 @@ openclaw memory rem-backfill --path ./memory --stage-short-term
|
||||
- `plugins.entries.voice-call.config.streaming.sttProvider` → `plugins.entries.voice-call.config.streaming.provider`
|
||||
- `plugins.entries.voice-call.config.streaming.openaiApiKey|sttModel|silenceDurationMs|vadThreshold` → `plugins.entries.voice-call.config.streaming.providers.openai.*`
|
||||
- `bindings[].match.accountID` → `bindings[].match.accountId`
|
||||
- Для каналів з іменованими `accounts`, але із залишковими значеннями каналу верхнього рівня для одного облікового запису, перемістіть ці значення з областю дії облікового запису в підвищений обліковий запис, вибраний для цього каналу (`accounts.default` для більшості каналів; Matrix може зберегти наявну відповідну іменовану/типову ціль)
|
||||
- Для каналів з іменованими `accounts`, але із залишковими верхньорівневими значеннями каналу для одного акаунта, перемістіть ці значення з областю акаунта до підвищеного акаунта, вибраного для цього каналу (`accounts.default` для більшості каналів; Matrix може зберегти наявну відповідну іменовану/стандартну ціль)
|
||||
- `identity` → `agents.list[].identity`
|
||||
- `agent.*` → `agents.defaults` + `tools.*` (tools/elevated/exec/sandbox/subagents)
|
||||
- `agent.model`/`allowedModels`/`modelAliases`/`modelFallbacks`/`imageModelFallbacks` → `agents.defaults.models` + `agents.defaults.model.primary/fallbacks` + `agents.defaults.imageModel.primary/fallbacks`
|
||||
@ -220,276 +221,276 @@ openclaw memory rem-backfill --path ./memory --stage-short-term
|
||||
- `browser.ssrfPolicy.allowPrivateNetwork` → `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork`
|
||||
- `browser.profiles.*.driver: "extension"` → `"existing-session"`
|
||||
- видаліть `browser.relayBindHost` (застаріле налаштування ретранслятора розширення)
|
||||
- застаріле `models.providers.*.api: "openai"` → `"openai-completions"` (запуск gateway також пропускає провайдери, у яких `api` встановлено на майбутнє або невідоме значення enum, замість аварійного завершення у закритому стані)
|
||||
- застаріле `models.providers.*.api: "openai"` → `"openai-completions"` (запуск Gateway також пропускає провайдерів, у яких `api` встановлено в майбутнє або невідоме значення enum, замість аварійного завершення в закритому режимі)
|
||||
|
||||
Попередження doctor також містять настанови щодо типового облікового запису для багатооблікових каналів:
|
||||
Попередження doctor також містять рекомендації щодо стандартного акаунта для багатьохакаунтових каналів:
|
||||
|
||||
- Якщо налаштовано два або більше записів `channels.<channel>.accounts` без `channels.<channel>.defaultAccount` або `accounts.default`, doctor попереджає, що резервна маршрутизація може вибрати неочікуваний обліковий запис.
|
||||
- Якщо `channels.<channel>.defaultAccount` встановлено на невідомий ID облікового запису, doctor попереджає і перелічує налаштовані ID облікових записів.
|
||||
- Якщо налаштовано два або більше записів `channels.<channel>.accounts` без `channels.<channel>.defaultAccount` або `accounts.default`, doctor попереджає, що резервна маршрутизація може вибрати неочікуваний акаунт.
|
||||
- Якщо `channels.<channel>.defaultAccount` встановлено на невідомий ID акаунта, doctor попереджає та перелічує налаштовані ID акаунтів.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="2b. Перевизначення провайдера OpenCode">
|
||||
Якщо ви вручну додали `models.providers.opencode`, `opencode-zen` або `opencode-go`, це перевизначає вбудований каталог OpenCode з `@mariozechner/pi-ai`. Це може примусово спрямувати моделі на неправильний API або обнулити вартість. Doctor попереджає, щоб ви могли видалити перевизначення і відновити маршрутизацію API та вартість для кожної моделі.
|
||||
Якщо ви вручну додали `models.providers.opencode`, `opencode-zen` або `opencode-go`, це перевизначає вбудований каталог OpenCode з `@mariozechner/pi-ai`. Це може примусово спрямувати моделі на неправильний API або обнулити витрати. Doctor попереджає, щоб ви могли видалити перевизначення й відновити маршрутизацію API та витрати для кожної моделі.
|
||||
</Accordion>
|
||||
<Accordion title="2c. Міграція браузера і готовність Chrome MCP">
|
||||
Якщо ваша конфігурація браузера все ще вказує на видалений шлях розширення Chrome, doctor нормалізує її до поточної моделі підключення host-local Chrome MCP:
|
||||
<Accordion title="2c. Міграція браузера та готовність Chrome MCP">
|
||||
Якщо ваша конфігурація браузера все ще вказує на видалений шлях розширення Chrome, doctor нормалізує її до поточної моделі приєднання Chrome MCP на локальному хості:
|
||||
|
||||
- `browser.profiles.*.driver: "extension"` стає `"existing-session"`
|
||||
- `browser.relayBindHost` видаляється
|
||||
|
||||
Doctor також перевіряє шлях host-local Chrome MCP, коли ви використовуєте `defaultProfile: "user"` або налаштований профіль `existing-session`:
|
||||
Doctor також перевіряє шлях Chrome MCP на локальному хості, коли ви використовуєте `defaultProfile: "user"` або налаштований профіль `existing-session`:
|
||||
|
||||
- перевіряє, чи Google Chrome встановлено на тому самому хості для типових профілів автоматичного підключення
|
||||
- перевіряє виявлену версію Chrome і попереджає, коли вона нижча за Chrome 144
|
||||
- нагадує увімкнути віддалене налагодження на сторінці інспектування браузера (наприклад, `chrome://inspect/#remote-debugging`, `brave://inspect/#remote-debugging` або `edge://inspect/#remote-debugging`)
|
||||
- перевіряє, чи встановлено Google Chrome на тому самому хості для стандартних профілів автоматичного підключення
|
||||
- перевіряє виявлену версію Chrome і попереджає, якщо вона нижча за Chrome 144
|
||||
- нагадує ввімкнути віддалене налагодження на сторінці інспектування браузера (наприклад `chrome://inspect/#remote-debugging`, `brave://inspect/#remote-debugging` або `edge://inspect/#remote-debugging`)
|
||||
|
||||
Doctor не може ввімкнути налаштування на стороні Chrome замість вас. Host-local Chrome MCP усе ще потребує:
|
||||
Doctor не може ввімкнути налаштування на боці Chrome за вас. Chrome MCP на локальному хості все ще потребує:
|
||||
|
||||
- браузера на основі Chromium 144+ на хості gateway/node
|
||||
- локально запущеного браузера
|
||||
- увімкненого віддаленого налагодження в цьому браузері
|
||||
- схвалення першого запиту згоди на підключення в браузері
|
||||
- підтвердження першого запиту згоди на приєднання в браузері
|
||||
|
||||
Готовність тут стосується лише передумов локального підключення. Existing-session зберігає поточні обмеження маршрутів Chrome MCP; розширені маршрути, як-от `responsebody`, експорт PDF, перехоплення завантажень і пакетні дії, усе ще потребують керованого браузера або сирого профілю CDP.
|
||||
Готовність тут стосується лише передумов локального приєднання. Existing-session зберігає поточні обмеження маршрутів Chrome MCP; розширені маршрути, як-от `responsebody`, експорт PDF, перехоплення завантажень і пакетні дії, все ще потребують керованого браузера або сирого профілю CDP.
|
||||
|
||||
Ця перевірка **не** застосовується до Docker, sandbox, remote-browser або інших headless-потоків. Вони й надалі використовують сирий CDP.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="2d. Передумови OAuth TLS">
|
||||
Коли налаштовано профіль OpenAI Codex OAuth, doctor перевіряє кінцеву точку авторизації OpenAI, щоб переконатися, що локальний стек Node/OpenSSL TLS може перевірити ланцюжок сертифікатів. Якщо перевірка завершується помилкою сертифіката (наприклад, `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, прострочений сертифікат або самопідписаний сертифікат), doctor виводить настанови з виправлення для конкретної платформи. На macOS з Homebrew Node виправленням зазвичай є `brew postinstall ca-certificates`. З `--deep` перевірка виконується навіть тоді, коли gateway справний.
|
||||
Коли налаштовано профіль OpenAI Codex OAuth, doctor перевіряє кінцеву точку авторизації OpenAI, щоб підтвердити, що локальний стек Node/OpenSSL TLS може перевірити ланцюжок сертифікатів. Якщо перевірка завершується помилкою сертифіката (наприклад `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, прострочений сертифікат або самопідписаний сертифікат), doctor виводить рекомендації щодо виправлення для конкретної платформи. На macOS з Homebrew Node виправленням зазвичай є `brew postinstall ca-certificates`. З `--deep` перевірка виконується навіть якщо gateway справний.
|
||||
</Accordion>
|
||||
<Accordion title="2e. Перевизначення провайдера Codex OAuth">
|
||||
Якщо раніше ви додали застарілі налаштування транспорту OpenAI у `models.providers.openai-codex`, вони можуть затіняти вбудований шлях провайдера Codex OAuth, який новіші випуски використовують автоматично. Doctor попереджає, коли бачить ці старі налаштування транспорту поряд із Codex OAuth, щоб ви могли видалити або переписати застаріле перевизначення транспорту і повернути вбудовану поведінку маршрутизації/резервування. Користувацькі проксі та перевизначення лише заголовків усе ще підтримуються і не запускають це попередження.
|
||||
Якщо раніше ви додали застарілі налаштування транспорту OpenAI у `models.providers.openai-codex`, вони можуть затінити вбудований шлях провайдера Codex OAuth, який новіші випуски використовують автоматично. Doctor попереджає, коли бачить ці старі налаштування транспорту поруч із Codex OAuth, щоб ви могли видалити або переписати застаріле перевизначення транспорту й повернути вбудовану маршрутизацію/резервну поведінку. Користувацькі проксі та перевизначення лише заголовків усе ще підтримуються й не викликають це попередження.
|
||||
</Accordion>
|
||||
<Accordion title="2f. Попередження маршрутів Codex plugin">
|
||||
Коли вбудований Codex plugin увімкнено, doctor також перевіряє, чи посилання на первинні моделі `openai-codex/*` досі розв'язуються через типовий PI runner. Така комбінація чинна, коли ви хочете використовувати автентифікацію Codex OAuth/підписки через PI, але її легко сплутати з нативним app-server harness Codex. Doctor попереджає і вказує на явну форму app-server: `openai/*` плюс `agentRuntime.id: "codex"` або `OPENCLAW_AGENT_RUNTIME=codex`.
|
||||
<Accordion title="2f. Попередження маршрутів Plugin Codex">
|
||||
Коли ввімкнено вбудований Plugin Codex, doctor також перевіряє, чи посилання первинних моделей `openai-codex/*` усе ще розв’язуються через стандартний PI runner. Така комбінація чинна, коли вам потрібна автентифікація Codex OAuth/підписки через PI, але її легко сплутати з нативним app-server harness Codex. Doctor попереджає та вказує на явну форму app-server: `openai/*` плюс `agentRuntime.id: "codex"` або `OPENCLAW_AGENT_RUNTIME=codex`.
|
||||
|
||||
Doctor не виправляє це автоматично, бо обидва маршрути чинні:
|
||||
Doctor не виправляє це автоматично, тому що обидва маршрути чинні:
|
||||
|
||||
- `openai-codex/*` + PI означає "використовувати автентифікацію Codex OAuth/підписки через звичайний runner OpenClaw."
|
||||
- `openai/*` + `agentRuntime.id: "codex"` означає "запустити вбудований turn через нативний app-server Codex."
|
||||
- `/codex ...` означає "керувати або прив'язати нативну розмову Codex з чату."
|
||||
- `/acp ...` або `runtime: "acp"` означає "використовувати зовнішній адаптер ACP/acpx."
|
||||
- `openai-codex/*` + PI означає «використовувати автентифікацію Codex OAuth/підписки через звичайний runner OpenClaw».
|
||||
- `openai/*` + `agentRuntime.id: "codex"` означає «виконувати вбудований хід через нативний app-server Codex».
|
||||
- `/codex ...` означає «керувати або прив’язати нативну розмову Codex з чату».
|
||||
- `/acp ...` або `runtime: "acp"` означає «використовувати зовнішній адаптер ACP/acpx».
|
||||
|
||||
Якщо з'являється попередження, виберіть потрібний маршрут і відредагуйте конфігурацію вручну. Залиште попередження як є, коли PI Codex OAuth є навмисним.
|
||||
Якщо з’являється попередження, виберіть потрібний маршрут і вручну відредагуйте конфігурацію. Залиште попередження без змін, коли PI Codex OAuth є навмисним.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="3. Міграції застарілого стану (розкладка диска)">
|
||||
Doctor може мігрувати старіші розкладки на диску в поточну структуру:
|
||||
<Accordion title="3. Міграції застарілого стану (структура диска)">
|
||||
Doctor може мігрувати старіші дискові структури в поточну структуру:
|
||||
|
||||
- Сховище сесій + транскрипти:
|
||||
- з `~/.openclaw/sessions/` до `~/.openclaw/agents/<agentId>/sessions/`
|
||||
- Каталог агента:
|
||||
- з `~/.openclaw/agent/` до `~/.openclaw/agents/<agentId>/agent/`
|
||||
- Стан автентифікації WhatsApp (Baileys):
|
||||
- із застарілих `~/.openclaw/credentials/*.json` (крім `oauth.json`)
|
||||
- до `~/.openclaw/credentials/whatsapp/<accountId>/...` (типовий ID облікового запису: `default`)
|
||||
- із застарілого `~/.openclaw/credentials/*.json` (крім `oauth.json`)
|
||||
- до `~/.openclaw/credentials/whatsapp/<accountId>/...` (стандартний id акаунта: `default`)
|
||||
|
||||
Ці міграції виконуються за принципом найкращого зусилля та є ідемпотентними; doctor виводитиме попередження, коли залишає будь-які застарілі папки як резервні копії. Gateway/CLI також автоматично мігрує застарілі сесії + каталог агента під час запуску, щоб історія/автентифікація/моделі потрапили у шлях для конкретного агента без ручного запуску doctor. Нормалізація провайдера talk/мапи провайдерів тепер порівнює за структурною рівністю, тому відмінності лише в порядку ключів більше не запускають повторні no-op зміни `doctor --fix`.
|
||||
Ці міграції виконуються за принципом best-effort та є ідемпотентними; doctor видаватиме попередження, коли залишатиме будь-які застарілі папки як резервні копії. Gateway/CLI також автоматично мігрує застарілі сесії + каталог агента під час запуску, щоб історія/автентифікація/моделі потрапляли в шлях для конкретного агента без ручного запуску doctor. Автентифікація WhatsApp навмисно мігрується лише через `openclaw doctor`. Нормалізація talk-провайдера/мапи провайдерів тепер порівнює за структурною рівністю, тому відмінності лише в порядку ключів більше не спричиняють повторні no-op зміни `doctor --fix`.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="3a. Міграції застарілих маніфестів plugin">
|
||||
Doctor сканує всі встановлені маніфести plugin на наявність застарілих ключів можливостей верхнього рівня (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders`). Коли їх знайдено, він пропонує перемістити їх до об'єкта `contracts` і переписати файл маніфесту на місці. Ця міграція ідемпотентна; якщо ключ `contracts` уже має ті самі значення, застарілий ключ видаляється без дублювання даних.
|
||||
<Accordion title="3a. Міграції застарілих маніфестів Plugin">
|
||||
Doctor сканує всі встановлені маніфести Plugin на наявність застарілих верхньорівневих ключів можливостей (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders`). Коли їх знайдено, він пропонує перемістити їх в об’єкт `contracts` і переписати файл маніфесту на місці. Ця міграція ідемпотентна; якщо ключ `contracts` уже має ті самі значення, застарілий ключ видаляється без дублювання даних.
|
||||
</Accordion>
|
||||
<Accordion title="3b. Міграції застарілого сховища cron">
|
||||
Doctor також перевіряє сховище завдань cron (`~/.openclaw/cron/jobs.json` типово або `cron.store`, коли перевизначено) на наявність старих форм завдань, які планувальник усе ще приймає для сумісності.
|
||||
Doctor також перевіряє сховище завдань cron (`~/.openclaw/cron/jobs.json` за замовчуванням або `cron.store`, якщо перевизначено) на старі форми завдань, які планувальник досі приймає для сумісності.
|
||||
|
||||
Поточні очищення cron включають:
|
||||
|
||||
- `jobId` → `id`
|
||||
- `schedule.cron` → `schedule.expr`
|
||||
- поля payload верхнього рівня (`message`, `model`, `thinking`, ...) → `payload`
|
||||
- поля delivery верхнього рівня (`deliver`, `channel`, `to`, `provider`, ...) → `delivery`
|
||||
- delivery-псевдоніми `provider` у payload → явний `delivery.channel`
|
||||
- верхньорівневі поля payload (`message`, `model`, `thinking`, ...) → `payload`
|
||||
- верхньорівневі поля доставки (`deliver`, `channel`, `to`, `provider`, ...) → `delivery`
|
||||
- псевдоніми доставки payload `provider` → явний `delivery.channel`
|
||||
- прості застарілі резервні завдання webhook `notify: true` → явний `delivery.mode="webhook"` з `delivery.to=cron.webhook`
|
||||
|
||||
Doctor автоматично мігрує завдання `notify: true` лише тоді, коли може зробити це без зміни поведінки. Якщо завдання поєднує застарілий резервний notify з наявним режимом доставки не через webhook, doctor попереджає і залишає це завдання для ручного перегляду.
|
||||
Doctor автоматично мігрує завдання `notify: true` лише тоді, коли це можна зробити без зміни поведінки. Якщо завдання поєднує застарілий резерв notify з наявним режимом доставки не через webhook, doctor попереджає й залишає це завдання для ручного перегляду.
|
||||
|
||||
На Linux doctor також попереджає, коли crontab користувача все ще викликає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`. Цей host-local скрипт не підтримується поточним OpenClaw і може записувати хибні повідомлення `Gateway inactive` до `~/.openclaw/logs/whatsapp-health.log`, коли cron не може дістатися до користувацької шини systemd. Видаліть застарілий запис crontab за допомогою `crontab -e`; використовуйте `openclaw channels status --probe`, `openclaw doctor` і `openclaw gateway status` для поточних перевірок справності.
|
||||
На Linux doctor також попереджає, коли crontab користувача все ще викликає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`. Цей скрипт на локальному хості не підтримується поточним OpenClaw і може записувати хибні повідомлення `Gateway inactive` у `~/.openclaw/logs/whatsapp-health.log`, коли cron не може дістатися до користувацької шини systemd. Видаліть застарілий запис crontab за допомогою `crontab -e`; використовуйте `openclaw channels status --probe`, `openclaw doctor` і `openclaw gateway status` для поточних перевірок стану.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="3c. Очищення блокувань сеансів">
|
||||
Doctor сканує кожен каталог сеансів агентів на наявність застарілих файлів блокування запису — файлів, що залишилися після аварійного завершення сеансу. Для кожного знайденого файлу блокування він повідомляє: шлях, PID, чи PID досі активний, вік блокування та чи вважається воно застарілим (мертвий PID або старіше за 30 хвилин). У режимі `--fix` / `--repair` він автоматично видаляє застарілі файли блокування; інакше друкує примітку та вказує повторно запустити з `--fix`.
|
||||
Doctor сканує кожен каталог сеансів агентів на наявність застарілих файлів блокування запису — файлів, що залишилися після аварійного завершення сеансу. Для кожного знайденого файла блокування він повідомляє: шлях, PID, чи PID ще активний, вік блокування та чи вважається воно застарілим (мертвий PID або старше 30 хвилин). У режимі `--fix` / `--repair` він автоматично видаляє застарілі файли блокування; інакше друкує примітку та вказує повторно запустити з `--fix`.
|
||||
</Accordion>
|
||||
<Accordion title="3d. Виправлення гілки транскрипту сеансу">
|
||||
Doctor сканує JSONL-файли сеансів агентів на дубльовану форму гілки, створену помилкою переписування транскрипту промпта від 2026.4.24: покинутий хід користувача з внутрішнім runtime-контекстом OpenClaw плюс активний сусідній елемент із тим самим видимим промптом користувача. У режимі `--fix` / `--repair` doctor створює резервну копію кожного ураженого файлу поруч з оригіналом і переписує транскрипт до активної гілки, щоб історія gateway і читачі пам’яті більше не бачили дубльованих ходів.
|
||||
<Accordion title="3d. Відновлення гілки стенограми сеансу">
|
||||
Doctor сканує JSONL-файли сеансів агентів на дубльовану форму гілки, створену помилкою переписування стенограми промптів 2026.4.24: покинутий хід користувача з внутрішнім runtime-контекстом OpenClaw плюс активний сусідній вузол із тим самим видимим промптом користувача. У режимі `--fix` / `--repair` doctor створює резервну копію кожного ураженого файла поруч з оригіналом і переписує стенограму на активну гілку, щоб історія gateway і читачі пам’яті більше не бачили дубльованих ходів.
|
||||
</Accordion>
|
||||
<Accordion title="4. Перевірки цілісності стану (збереження сеансів, маршрутизація та безпека)">
|
||||
Каталог стану — це операційний стовбур системи. Якщо він зникне, ви втратите сеанси, облікові дані, журнали та конфігурацію (якщо не маєте резервних копій деінде).
|
||||
Каталог стану — це операційний мозковий стовбур. Якщо він зникне, ви втратите сеанси, облікові дані, журнали та конфігурацію (якщо не маєте резервних копій деінде).
|
||||
|
||||
Doctor перевіряє:
|
||||
|
||||
- **Каталог стану відсутній**: попереджає про катастрофічну втрату стану, пропонує повторно створити каталог і нагадує, що не може відновити відсутні дані.
|
||||
- **Дозволи каталогу стану**: перевіряє можливість запису; пропонує виправити дозволи (і виводить підказку `chown`, коли виявлено невідповідність власника/групи).
|
||||
- **Синхронізований із хмарою каталог стану macOS**: попереджає, коли стан розміщується під iCloud Drive (`~/Library/Mobile Documents/com~apple~CloudDocs/...`) або `~/Library/CloudStorage/...`, оскільки шляхи з синхронізацією можуть спричиняти повільніше I/O та перегони блокування/синхронізації.
|
||||
- **Каталог стану Linux на SD або eMMC**: попереджає, коли стан розміщується на джерелі монтування `mmcblk*`, оскільки випадкове I/O на SD або eMMC може бути повільнішим і швидше зношувати носій під час записів сеансів та облікових даних.
|
||||
- **Каталоги сеансів відсутні**: `sessions/` і каталог сховища сеансів потрібні для збереження історії та уникнення збоїв `ENOENT`.
|
||||
- **Невідповідність транскрипту**: попереджає, коли в нещодавніх записах сеансів відсутні файли транскриптів.
|
||||
- **Основний сеанс "1-line JSONL"**: позначає випадок, коли основний транскрипт має лише один рядок (історія не накопичується).
|
||||
- **Кілька каталогів стану**: попереджає, коли в домашніх каталогах існує кілька папок `~/.openclaw` або коли `OPENCLAW_STATE_DIR` вказує в інше місце (історія може розділятися між інсталяціями).
|
||||
- **Каталог стану macOS, синхронізований із хмарою**: попереджає, коли стан розташований у iCloud Drive (`~/Library/Mobile Documents/com~apple~CloudDocs/...`) або `~/Library/CloudStorage/...`, бо шляхи з синхронізацією можуть спричиняти повільніший I/O і перегони блокувань/синхронізації.
|
||||
- **Каталог стану Linux на SD або eMMC**: попереджає, коли стан розташований на джерелі монтування `mmcblk*`, бо випадковий I/O на SD або eMMC може бути повільнішим і швидше зношувати носій під час записів сеансів та облікових даних.
|
||||
- **Каталоги сеансів відсутні**: `sessions/` і каталог сховища сеансів потрібні для збереження історії та уникнення аварій `ENOENT`.
|
||||
- **Невідповідність стенограм**: попереджає, коли в нещодавніх записах сеансів бракує файлів стенограм.
|
||||
- **Основний сеанс "1-line JSONL"**: позначає випадки, коли основна стенограма має лише один рядок (історія не накопичується).
|
||||
- **Кілька каталогів стану**: попереджає, коли в різних домашніх каталогах існує кілька папок `~/.openclaw` або коли `OPENCLAW_STATE_DIR` вказує деінде (історія може розділитися між інсталяціями).
|
||||
- **Нагадування про віддалений режим**: якщо `gateway.mode=remote`, doctor нагадує запустити його на віддаленому хості (стан зберігається там).
|
||||
- **Дозволи файлу конфігурації**: попереджає, якщо `~/.openclaw/openclaw.json` доступний для читання групі/всім, і пропонує посилити дозволи до `600`.
|
||||
- **Дозволи файла конфігурації**: попереджає, якщо `~/.openclaw/openclaw.json` доступний для читання групі/усім, і пропонує посилити дозволи до `600`.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="5. Стан автентифікації моделі (закінчення строку OAuth)">
|
||||
Doctor перевіряє профілі OAuth у сховищі автентифікації, попереджає, коли строк дії токенів минає або вже минув, і може безпечно оновити їх. Якщо профіль Anthropic OAuth/token застарів, він пропонує ключ API Anthropic або шлях setup-token Anthropic. Запити на оновлення з’являються лише під час інтерактивного запуску (TTY); `--non-interactive` пропускає спроби оновлення.
|
||||
<Accordion title="5. Стан автентифікації моделей (закінчення OAuth)">
|
||||
Doctor перевіряє OAuth-профілі у сховищі автентифікації, попереджає, коли токени скоро закінчаться або вже закінчилися, і може оновити їх, коли це безпечно. Якщо OAuth/токен-профіль Anthropic застарів, він пропонує API-ключ Anthropic або шлях із setup-token Anthropic. Запити на оновлення з’являються лише під час інтерактивного запуску (TTY); `--non-interactive` пропускає спроби оновлення.
|
||||
|
||||
Коли оновлення OAuth остаточно не вдається (наприклад, `refresh_token_reused`, `invalid_grant` або провайдер просить увійти знову), doctor повідомляє, що потрібна повторна автентифікація, і друкує точну команду `openclaw models auth login --provider ...` для запуску.
|
||||
Коли оновлення OAuth остаточно не вдається (наприклад `refresh_token_reused`, `invalid_grant` або провайдер вимагає ввійти знову), doctor повідомляє, що потрібна повторна автентифікація, і друкує точну команду `openclaw models auth login --provider ...`, яку слід виконати.
|
||||
|
||||
Doctor також повідомляє про профілі автентифікації, які тимчасово непридатні через:
|
||||
Doctor також повідомляє про профілі автентифікації, тимчасово непридатні через:
|
||||
|
||||
- короткі періоди очікування (обмеження швидкості/тайм-аути/збої автентифікації)
|
||||
- довші вимкнення (збої оплати/кредитів)
|
||||
- короткі періоди очікування (обмеження частоти/тайм-аути/помилки автентифікації)
|
||||
- довші вимкнення (помилки білінгу/кредитів)
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="6. Валідація моделі hooks">
|
||||
<Accordion title="6. Перевірка моделі hooks">
|
||||
Якщо встановлено `hooks.gmail.model`, doctor перевіряє посилання на модель за каталогом і allowlist та попереджає, коли воно не розв’яжеться або заборонене.
|
||||
</Accordion>
|
||||
<Accordion title="7. Відновлення образу пісочниці">
|
||||
Коли sandboxing увімкнено, doctor перевіряє образи Docker і пропонує зібрати або перейти на застарілі назви, якщо поточного образу немає.
|
||||
Коли пісочницю ввімкнено, doctor перевіряє образи Docker і пропонує зібрати їх або перемкнутися на застарілі назви, якщо поточний образ відсутній.
|
||||
</Accordion>
|
||||
<Accordion title="7b. Очищення інсталяції Plugin">
|
||||
Doctor видаляє застарілий згенерований OpenClaw проміжний стан залежностей Plugin у режимі `openclaw doctor --fix` / `openclaw doctor --repair`. Це охоплює застарілі згенеровані корені залежностей, старі каталоги install-stage і локальні для пакета залишки від попереднього коду відновлення залежностей bundled-plugin.
|
||||
<Accordion title="7b. Очищення встановлення Plugin">
|
||||
Doctor видаляє застарілий проміжний стан залежностей Plugin, згенерований OpenClaw, у режимі `openclaw doctor --fix` / `openclaw doctor --repair`. Це охоплює застарілі згенеровані корені залежностей, старі каталоги етапу встановлення та локальне для пакета сміття від попереднього коду відновлення залежностей bundled-plugin.
|
||||
|
||||
Doctor також може перевстановити налаштовані завантажувані plugins, коли конфігурація посилається на них, але локальний реєстр plugin не може їх знайти. Для externalization bundled-plugin у 2026.5.2 doctor автоматично встановлює завантажувані plugins, які вже використовує наявна конфігурація, а потім покладається на `meta.lastTouchedVersion`, щоб виконати цей релізний прохід лише один раз. Запуск Gateway і перезавантаження конфігурації не запускають менеджери пакетів; інсталяції plugin залишаються явною роботою doctor/install/update.
|
||||
Doctor також може перевстановити налаштовані завантажувані plugins, коли конфігурація посилається на них, але локальний реєстр plugins не може їх знайти. Для externalization bundled-plugin 2026.5.2 doctor автоматично встановлює завантажувані plugins, які вже використовує наявна конфігурація, а потім покладається на `meta.lastTouchedVersion`, щоб виконати цей релізний прохід лише один раз. Запуск Gateway і перезавантаження конфігурації не запускають менеджери пакетів; встановлення plugins лишається явною роботою doctor/install/update.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="8. Міграції сервісу Gateway і підказки з очищення">
|
||||
Doctor виявляє застарілі сервіси gateway (launchd/systemd/schtasks) і пропонує видалити їх та встановити сервіс OpenClaw з використанням поточного порту gateway. Він також може сканувати наявність додаткових сервісів, схожих на gateway, і друкувати підказки з очищення. Сервіси gateway OpenClaw з іменами профілів вважаються повноцінними та не позначаються як "додаткові."
|
||||
<Accordion title="8. Міграції служби Gateway і підказки з очищення">
|
||||
Doctor виявляє застарілі служби gateway (launchd/systemd/schtasks) і пропонує видалити їх та встановити службу OpenClaw з використанням поточного порту gateway. Він також може сканувати додаткові служби, схожі на gateway, і друкувати підказки з очищення. Служби OpenClaw gateway з назвами профілів вважаються повноцінними й не позначаються як "extra."
|
||||
|
||||
У Linux, якщо сервіс gateway на рівні користувача відсутній, але існує сервіс gateway OpenClaw на рівні системи, doctor не встановлює автоматично другий сервіс на рівні користувача. Перевірте за допомогою `openclaw gateway status --deep` або `openclaw doctor --deep`, а потім видаліть дублікат або встановіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли системний супервізор керує життєвим циклом gateway.
|
||||
У Linux, якщо служба gateway рівня користувача відсутня, але існує служба OpenClaw gateway системного рівня, doctor не встановлює другу службу рівня користувача автоматично. Перевірте через `openclaw gateway status --deep` або `openclaw doctor --deep`, потім видаліть дублікат або встановіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли системний supervisor керує життєвим циклом gateway.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="8b. Міграція запуску Matrix">
|
||||
Коли обліковий запис каналу Matrix має очікувану або доступну для виконання міграцію застарілого стану, doctor (у режимі `--fix` / `--repair`) створює знімок перед міграцією, а потім виконує best-effort кроки міграції: міграцію застарілого стану Matrix і підготовку застарілого зашифрованого стану. Обидва кроки не є фатальними; помилки журналюються, а запуск продовжується. У режимі лише читання (`openclaw doctor` без `--fix`) ця перевірка повністю пропускається.
|
||||
<Accordion title="8b. Міграція Startup Matrix">
|
||||
Коли обліковий запис каналу Matrix має очікувану або придатну до дії міграцію застарілого стану, doctor (у режимі `--fix` / `--repair`) створює знімок перед міграцією, а потім виконує best-effort кроки міграції: міграцію застарілого стану Matrix і підготовку застарілого зашифрованого стану. Обидва кроки не є фатальними; помилки журналюються, а запуск продовжується. У режимі лише читання (`openclaw doctor` без `--fix`) цю перевірку повністю пропущено.
|
||||
</Accordion>
|
||||
<Accordion title="8c. Сполучення пристрою та дрейф автентифікації">
|
||||
Doctor тепер перевіряє стан сполучення пристрою як частину звичайного проходу перевірки стану.
|
||||
<Accordion title="8c. Сполучення пристроїв і дрейф автентифікації">
|
||||
Doctor тепер перевіряє стан сполучення пристроїв як частину звичайного проходу перевірки здоров’я.
|
||||
|
||||
Що він повідомляє:
|
||||
|
||||
- запити на перше спарювання, що очікують
|
||||
- підвищення ролі для вже спарених пристроїв, що очікують
|
||||
- розширення області доступу для вже спарених пристроїв, що очікують
|
||||
- виправлення невідповідності публічного ключа, коли ідентифікатор пристрою все ще збігається, але ідентичність пристрою більше не збігається із затвердженим записом
|
||||
- спарені записи без активного токена для затвердженої ролі
|
||||
- спарені токени, чиї області доступу відхилилися від затвердженої базової лінії спарювання
|
||||
- локальні кешовані записи токенів пристрою для поточної машини, які передують ротації токена на боці gateway або містять застарілі метадані області доступу
|
||||
- очікувані запити першого сполучення
|
||||
- очікувані підвищення ролі для вже сполучених пристроїв
|
||||
- очікувані підвищення scope для вже сполучених пристроїв
|
||||
- відновлення невідповідності публічного ключа, коли id пристрою все ще збігається, але ідентичність пристрою більше не збігається зі схваленим записом
|
||||
- сполучені записи, у яких немає активного токена для схваленої ролі
|
||||
- сполучені токени, чиї scopes відхилилися за межі схваленої базової лінії сполучення
|
||||
- локальні кешовані записи device-token для поточної машини, що передують ротації токена на боці gateway або мають застарілі метадані scope
|
||||
|
||||
Засіб діагностики не затверджує запити на спарювання автоматично й не виконує автоматичну ротацію токенів пристроїв. Натомість він друкує точні наступні кроки:
|
||||
Doctor не схвалює запити сполучення автоматично і не виконує автоматичну ротацію токенів пристроїв. Натомість він друкує точні наступні кроки:
|
||||
|
||||
- перегляньте запити, що очікують, за допомогою `openclaw devices list`
|
||||
- затвердьте точний запит за допомогою `openclaw devices approve <requestId>`
|
||||
- виконайте ротацію нового токена за допомогою `openclaw devices rotate --device <deviceId> --role <role>`
|
||||
- видаліть і повторно затвердьте застарілий запис за допомогою `openclaw devices remove <deviceId>`
|
||||
- переглянути очікувані запити за допомогою `openclaw devices list`
|
||||
- схвалити точний запит за допомогою `openclaw devices approve <requestId>`
|
||||
- ротувати свіжий токен за допомогою `openclaw devices rotate --device <deviceId> --role <role>`
|
||||
- видалити та повторно схвалити застарілий запис за допомогою `openclaw devices remove <deviceId>`
|
||||
|
||||
Це закриває поширену прогалину "уже спарено, але все ще з'являється вимога спарювання": тепер засіб діагностики відрізняє перше спарювання від очікуваних підвищень ролі/області доступу та від дрейфу застарілого токена/ідентичності пристрою.
|
||||
Це закриває поширену прогалину "already paired but still getting pairing required": doctor тепер відрізняє перше сполучення від очікуваних підвищень ролі/scope і від дрейфу застарілого токена/ідентичності пристрою.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="9. Попередження безпеки">
|
||||
Засіб діагностики видає попередження, коли провайдер відкритий для особистих повідомлень без allowlist або коли політику налаштовано небезпечним способом.
|
||||
Doctor виводить попередження, коли провайдер відкритий для DM без allowlist або коли політика налаштована небезпечним чином.
|
||||
</Accordion>
|
||||
<Accordion title="10. systemd linger (Linux)">
|
||||
Якщо запуск відбувається як користувацька служба systemd, засіб діагностики перевіряє, що lingering увімкнено, щоб gateway залишався активним після виходу із системи.
|
||||
Якщо запущено як користувацьку службу systemd, doctor забезпечує ввімкнення lingering, щоб gateway залишався активним після виходу з системи.
|
||||
</Accordion>
|
||||
<Accordion title="11. Стан робочого простору (skills, plugins і застарілі каталоги)">
|
||||
Засіб діагностики друкує зведення стану робочого простору для агента за замовчуванням:
|
||||
<Accordion title="11. Стан робочої області (skills, plugins і застарілі каталоги)">
|
||||
Doctor друкує підсумок стану робочої області для стандартного агента:
|
||||
|
||||
- **Стан Skills**: підраховує skills, що відповідають вимогам, не мають вимог або заблоковані allowlist.
|
||||
- **Застарілі каталоги робочого простору**: попереджає, коли `~/openclaw` або інші застарілі каталоги робочого простору існують поряд із поточним робочим простором.
|
||||
- **Стан Plugin**: підраховує увімкнені/вимкнені/помилкові plugins; перелічує ідентифікатори plugins для будь-яких помилок; повідомляє про можливості пакетних plugins.
|
||||
- **Попередження сумісності Plugin**: позначає plugins, які мають проблеми сумісності з поточним середовищем виконання.
|
||||
- **Діагностика Plugin**: показує будь-які попередження або помилки під час завантаження, видані реєстром plugin.
|
||||
- **Стан Skills**: рахує придатні skills, skills з відсутніми вимогами та skills, заблоковані allowlist.
|
||||
- **Застарілі каталоги робочої області**: попереджає, коли `~/openclaw` або інші застарілі каталоги робочої області існують поруч із поточною робочою областю.
|
||||
- **Стан Plugin**: рахує ввімкнені/вимкнені/помилкові plugins; перелічує ID plugins для будь-яких помилок; повідомляє можливості bundle plugin.
|
||||
- **Попередження сумісності Plugin**: позначає plugins, що мають проблеми сумісності з поточним runtime.
|
||||
- **Діагностика Plugin**: показує будь-які попередження або помилки під час завантаження, виведені реєстром plugins.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="11b. Розмір bootstrap-файлу">
|
||||
Засіб діагностики перевіряє, чи bootstrap-файли робочого простору (наприклад `AGENTS.md`, `CLAUDE.md` або інші впроваджені файли контексту) наближаються до налаштованого бюджету символів або перевищують його. Він повідомляє для кожного файлу необроблену кількість символів порівняно з впровадженою, відсоток обрізання, причину обрізання (`max/file` або `max/total`) і загальну кількість впроваджених символів як частку від загального бюджету. Коли файли обрізано або вони близькі до ліміту, засіб діагностики друкує поради щодо налаштування `agents.defaults.bootstrapMaxChars` і `agents.defaults.bootstrapTotalMaxChars`.
|
||||
<Accordion title="11b. Розмір bootstrap-файла">
|
||||
Doctor перевіряє, чи bootstrap-файли робочої області (наприклад `AGENTS.md`, `CLAUDE.md` або інші інжектовані контекстні файли) наближаються до налаштованого бюджету символів або перевищують його. Він повідомляє для кожного файла сирі та інжектовані кількості символів, відсоток обрізання, причину обрізання (`max/file` або `max/total`) і загальну кількість інжектованих символів як частку загального бюджету. Коли файли обрізані або близькі до ліміту, doctor друкує поради з налаштування `agents.defaults.bootstrapMaxChars` і `agents.defaults.bootstrapTotalMaxChars`.
|
||||
</Accordion>
|
||||
<Accordion title="11d. Очищення застарілого channel plugin">
|
||||
Коли `openclaw doctor --fix` видаляє відсутній channel plugin, він також видаляє підвішену конфігурацію з областю каналу, яка посилалася на цей plugin: записи `channels.<id>`, цілі heartbeat, що називали канал, і перевизначення `agents.*.models["<channel>/*"]`. Це запобігає циклам завантаження Gateway, коли середовище виконання каналу зникло, але конфігурація все ще просить gateway прив'язатися до нього.
|
||||
<Accordion title="11d. Очищення застарілого Plugin каналу">
|
||||
Коли `openclaw doctor --fix` видаляє відсутній Plugin каналу, він також видаляє dangling конфігурацію в scope каналу, що посилалася на цей Plugin: записи `channels.<id>`, цілі heartbeat, що називали канал, і перевизначення `agents.*.models["<channel>/*"]`. Це запобігає циклам завантаження Gateway, коли runtime каналу зник, але конфігурація все ще просить gateway прив’язатися до нього.
|
||||
</Accordion>
|
||||
<Accordion title="11c. Автодоповнення оболонки">
|
||||
Засіб діагностики перевіряє, чи встановлено автодоповнення клавішею Tab для поточної оболонки (zsh, bash, fish або PowerShell):
|
||||
Doctor перевіряє, чи встановлено автодоповнення клавішею Tab для поточної оболонки (zsh, bash, fish або PowerShell):
|
||||
|
||||
- Якщо профіль оболонки використовує повільний динамічний шаблон доповнення (`source <(openclaw completion ...)`), засіб діагностики оновлює його до швидшого варіанта кешованого файлу.
|
||||
- Якщо доповнення налаштовано в профілі, але файл кешу відсутній, засіб діагностики автоматично регенерує кеш.
|
||||
- Якщо доповнення взагалі не налаштовано, засіб діагностики пропонує встановити його (лише в інтерактивному режимі; пропускається з `--non-interactive`).
|
||||
- Якщо профіль оболонки використовує повільний динамічний шаблон автодоповнення (`source <(openclaw completion ...)`), doctor оновлює його до швидшого варіанта з кешованим файлом.
|
||||
- Якщо автодоповнення налаштовано в профілі, але файл кешу відсутній, doctor автоматично регенерує кеш.
|
||||
- Якщо автодоповнення взагалі не налаштовано, doctor пропонує встановити його (лише інтерактивний режим; пропускається з `--non-interactive`).
|
||||
|
||||
Запустіть `openclaw completion --write-state`, щоб вручну регенерувати кеш.
|
||||
Запустіть `openclaw completion --write-state`, щоб регенерувати кеш вручну.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="12. Перевірки автентифікації Gateway (локальний токен)">
|
||||
Засіб діагностики перевіряє готовність локальної токен-автентифікації gateway.
|
||||
Doctor перевіряє готовність автентифікації токена локального gateway.
|
||||
|
||||
- Якщо режим токена потребує токена, а джерела токена немає, засіб діагностики пропонує згенерувати його.
|
||||
- Якщо `gateway.auth.token` керується SecretRef, але недоступний, засіб діагностики попереджає та не перезаписує його відкритим текстом.
|
||||
- Якщо режим токена потребує токена, а джерела токена немає, doctor пропонує згенерувати його.
|
||||
- Якщо `gateway.auth.token` керується SecretRef, але недоступний, doctor попереджає і не перезаписує його відкритим текстом.
|
||||
- `openclaw doctor --generate-gateway-token` примусово генерує токен лише тоді, коли не налаштовано SecretRef токена.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="12b. Виправлення лише для читання з урахуванням SecretRef">
|
||||
Деякі потоки виправлення мають перевіряти налаштовані облікові дані без послаблення поведінки швидкого збою під час виконання.
|
||||
<Accordion title="12b. SecretRef-aware відновлення лише для читання">
|
||||
Деяким потокам відновлення потрібно перевіряти налаштовані облікові дані, не послаблюючи fail-fast поведінку runtime.
|
||||
|
||||
- `openclaw doctor --fix` тепер використовує ту саму модель підсумку SecretRef лише для читання, що й команди сімейства status, для цільових виправлень конфігурації.
|
||||
- Приклад: виправлення Telegram `allowFrom` / `groupAllowFrom` `@username` намагається використовувати налаштовані облікові дані бота, коли вони доступні.
|
||||
- Якщо токен бота Telegram налаштовано через SecretRef, але він недоступний у поточному шляху команди, засіб діагностики повідомляє, що облікові дані налаштовані, але недоступні, і пропускає автоматичне розв'язання замість аварійного завершення або помилкового повідомлення, що токен відсутній.
|
||||
- `openclaw doctor --fix` тепер використовує ту саму модель read-only підсумку SecretRef, що й команди сімейства status, для цільових відновлень конфігурації.
|
||||
- Приклад: відновлення Telegram `allowFrom` / `groupAllowFrom` `@username` намагається використати налаштовані облікові дані бота, коли вони доступні.
|
||||
- Якщо токен бота Telegram налаштовано через SecretRef, але він недоступний у поточному шляху команди, doctor повідомляє, що облікові дані налаштовані, але недоступні, і пропускає автоматичне розв’язання замість аварійного завершення або помилкового повідомлення, що токен відсутній.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="13. Перевірка справності Gateway + перезапуск">
|
||||
Doctor виконує перевірку справності та пропонує перезапустити Gateway, коли він виглядає несправним.
|
||||
<Accordion title="13. Перевірка стану Gateway + перезапуск">
|
||||
Doctor виконує перевірку стану й пропонує перезапустити gateway, коли він виглядає несправним.
|
||||
</Accordion>
|
||||
<Accordion title="13b. Готовність пошуку пам’яті">
|
||||
Doctor перевіряє, чи налаштований постачальник ембедингів для пошуку пам’яті готовий для типового агента. Поведінка залежить від налаштованого бекенда та постачальника:
|
||||
Doctor перевіряє, чи налаштований постачальник embedding для пошуку пам’яті готовий для агента за замовчуванням. Поведінка залежить від налаштованого бекенда й постачальника:
|
||||
|
||||
- **Бекенд QMD**: перевіряє, чи доступний і придатний до запуску бінарний файл `qmd`. Якщо ні, виводить інструкції для виправлення, зокрема npm-пакет і варіант ручного шляху до бінарного файла.
|
||||
- **Бекенд QMD**: перевіряє, чи доступний і придатний до запуску бінарний файл `qmd`. Якщо ні, виводить підказки щодо виправлення, зокрема npm-пакет і варіант ручного шляху до бінарного файла.
|
||||
- **Явний локальний постачальник**: перевіряє наявність локального файла моделі або розпізнаної віддаленої/завантажуваної URL-адреси моделі. Якщо її немає, пропонує перейти на віддаленого постачальника.
|
||||
- **Явний віддалений постачальник** (`openai`, `voyage` тощо): перевіряє, чи є API-ключ у середовищі або сховищі автентифікації. Якщо його немає, виводить практичні підказки для виправлення.
|
||||
- **Автоматичний постачальник**: спершу перевіряє доступність локальної моделі, а потім пробує кожного віддаленого постачальника в порядку автоматичного вибору.
|
||||
- **Явний віддалений постачальник** (`openai`, `voyage` тощо): перевіряє наявність API-ключа в середовищі або сховищі автентифікації. Якщо його немає, виводить практичні підказки щодо виправлення.
|
||||
- **Автоматичний постачальник**: спочатку перевіряє доступність локальної моделі, а потім пробує кожного віддаленого постачальника в порядку автоматичного вибору.
|
||||
|
||||
Коли доступний кешований результат зондування Gateway (Gateway був справним на момент перевірки), doctor зіставляє його результат із конфігурацією, видимою для CLI, і зазначає будь-яку розбіжність. Doctor не запускає новий ping ембедингів у типовому шляху; використовуйте команду глибокого стану пам’яті, коли потрібна жива перевірка постачальника.
|
||||
Коли доступний кешований результат проби gateway (gateway був справним на момент перевірки), doctor зіставляє його результат із конфігурацією, видимою для CLI, і зазначає будь-яку невідповідність. Doctor не запускає новий embedding ping у стандартному шляху; використовуйте команду глибокого статусу пам’яті, коли потрібна жива перевірка постачальника.
|
||||
|
||||
Використовуйте `openclaw memory status --deep`, щоб перевірити готовність ембедингів під час виконання.
|
||||
Використовуйте `openclaw memory status --deep`, щоб перевірити готовність embedding під час виконання.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="14. Попередження про стан каналів">
|
||||
Якщо Gateway справний, doctor виконує зондування стану каналу та повідомляє попередження із запропонованими виправленнями.
|
||||
<Accordion title="14. Попередження про статус каналу">
|
||||
Якщо gateway справний, doctor запускає пробу статусу каналу й повідомляє попередження із запропонованими виправленнями.
|
||||
</Accordion>
|
||||
<Accordion title="15. Аудит і відновлення конфігурації супервізора">
|
||||
Doctor перевіряє встановлену конфігурацію супервізора (launchd/systemd/schtasks) на відсутні або застарілі типові параметри (наприклад, залежності systemd від network-online і затримку перезапуску). Коли він знаходить невідповідність, рекомендує оновлення та може переписати файл служби/завдання до поточних типових значень.
|
||||
Doctor перевіряє встановлену конфігурацію супервізора (launchd/systemd/schtasks) на відсутні або застарілі стандартні значення (наприклад, залежності systemd від network-online і затримку перезапуску). Коли він знаходить невідповідність, рекомендує оновлення й може переписати файл служби/завдання до поточних стандартних значень.
|
||||
|
||||
Примітки:
|
||||
|
||||
- `openclaw doctor` запитує підтвердження перед переписуванням конфігурації супервізора.
|
||||
- `openclaw doctor --yes` приймає типові запити на відновлення.
|
||||
- `openclaw doctor --yes` приймає стандартні запити на відновлення.
|
||||
- `openclaw doctor --repair` застосовує рекомендовані виправлення без запитів.
|
||||
- `openclaw doctor --repair --force` перезаписує власні конфігурації супервізора.
|
||||
- `OPENCLAW_SERVICE_REPAIR_POLICY=external` залишає doctor у режимі лише читання для життєвого циклу служби Gateway. Він усе одно повідомляє про справність служби та виконує відновлення, не пов’язані зі службою, але пропускає встановлення/запуск/перезапуск/bootstrap служби, переписування конфігурації супервізора та очищення застарілих служб, оскільки цим життєвим циклом керує зовнішній супервізор.
|
||||
- У Linux doctor не переписує метадані команди/точки входу, доки відповідний systemd unit Gateway активний. Він також ігнорує неактивні додаткові unit-и, схожі на Gateway, які не є застарілими, під час сканування дубльованих служб, щоб супровідні файли служб не створювали зайвий шум очищення.
|
||||
- Якщо автентифікація токеном вимагає токен і `gateway.auth.token` керується SecretRef, встановлення/відновлення служби doctor перевіряє SecretRef, але не зберігає розв’язані значення токена у відкритому тексті в метадані середовища служби супервізора.
|
||||
- Doctor виявляє керовані значення середовища служби на основі `.env`/SecretRef, які старіші встановлення LaunchAgent, systemd або Windows Scheduled Task вбудовували inline, і переписує метадані служби так, щоб ці значення завантажувалися з джерела виконання, а не з визначення супервізора.
|
||||
- Doctor виявляє, коли команда служби все ще закріплює старий `--port` після зміни `gateway.port`, і переписує метадані служби на поточний порт.
|
||||
- `openclaw doctor --repair --force` перезаписує користувацькі конфігурації супервізора.
|
||||
- `OPENCLAW_SERVICE_REPAIR_POLICY=external` залишає doctor у режимі лише читання для життєвого циклу служби gateway. Він усе ще повідомляє про стан служби й виконує відновлення, не пов’язані зі службою, але пропускає install/start/restart/bootstrap служби, переписування конфігурації супервізора й очищення застарілих служб, оскільки цим життєвим циклом керує зовнішній супервізор.
|
||||
- На Linux doctor не переписує метадані команди/entrypoint, доки відповідний systemd-unit gateway активний. Він також ігнорує неактивні не застарілі додаткові unit-и, схожі на gateway, під час сканування дублікатів служб, щоб супутні файли служб не створювали зайвого шуму очищення.
|
||||
- Якщо автентифікація токеном вимагає токен і `gateway.auth.token` керується через SecretRef, встановлення/відновлення служби doctor перевіряє SecretRef, але не зберігає розв’язані значення токена відкритим текстом у метадані середовища служби супервізора.
|
||||
- Doctor виявляє керовані значення середовища служби на основі `.env`/SecretRef, які старіші інсталяції LaunchAgent, systemd або Windows Scheduled Task вбудували inline, і переписує метадані служби так, щоб ці значення завантажувалися з runtime-джерела, а не з визначення супервізора.
|
||||
- Doctor виявляє, коли команда служби досі фіксує старий `--port` після зміни `gateway.port`, і переписує метадані служби на поточний порт.
|
||||
- Якщо автентифікація токеном вимагає токен, а налаштований SecretRef токена не розв’язується, doctor блокує шлях встановлення/відновлення з практичними інструкціями.
|
||||
- Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, doctor блокує встановлення/відновлення, доки режим не буде задано явно.
|
||||
- Для Linux user-systemd unit-ів перевірки дрейфу токена doctor тепер охоплюють джерела і `Environment=`, і `EnvironmentFile=` під час порівняння метаданих автентифікації служби.
|
||||
- Відновлення служби doctor відмовляються переписувати, зупиняти або перезапускати службу Gateway зі старішого бінарного файла OpenClaw, коли конфігурацію востаннє записала новіша версія. Див. [усунення несправностей Gateway](/uk/gateway/troubleshooting#split-brain-installs-and-newer-config-guard).
|
||||
- Для Linux user-systemd unit-ів перевірки розбіжності токенів doctor тепер охоплюють джерела `Environment=` і `EnvironmentFile=` під час порівняння метаданих автентифікації служби.
|
||||
- Відновлення служби doctor відмовляються переписувати, зупиняти або перезапускати службу gateway зі старішого бінарного файла OpenClaw, коли конфігурацію востаннє було записано новішою версією. Див. [усунення несправностей Gateway](/uk/gateway/troubleshooting#split-brain-installs-and-newer-config-guard).
|
||||
- Ви завжди можете примусово виконати повне переписування через `openclaw gateway install --force`.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="16. Діагностика середовища виконання Gateway + портів">
|
||||
Doctor перевіряє середовище виконання служби (PID, останній статус виходу) і попереджає, коли служба встановлена, але фактично не працює. Він також перевіряє конфлікти портів на порту Gateway (типово `18789`) і повідомляє ймовірні причини (Gateway уже запущено, SSH-тунель).
|
||||
<Accordion title="16. Діагностика runtime Gateway і порту">
|
||||
Doctor перевіряє runtime служби (PID, останній статус виходу) і попереджає, коли службу встановлено, але вона фактично не працює. Він також перевіряє конфлікти портів на порту gateway (стандартно `18789`) і повідомляє ймовірні причини (gateway уже працює, SSH-тунель).
|
||||
</Accordion>
|
||||
<Accordion title="17. Найкращі практики середовища виконання Gateway">
|
||||
Doctor попереджає, коли служба Gateway працює на Bun або шляху Node, керованому менеджером версій (`nvm`, `fnm`, `volta`, `asdf` тощо). Канали WhatsApp + Telegram потребують Node, а шляхи менеджера версій можуть ламатися після оновлень, бо служба не завантажує ініціалізацію вашої оболонки. Doctor пропонує перейти на системне встановлення Node, коли воно доступне (Homebrew/apt/choco).
|
||||
<Accordion title="17. Найкращі практики runtime Gateway">
|
||||
Doctor попереджає, коли служба gateway працює на Bun або шляху Node, керованому менеджером версій (`nvm`, `fnm`, `volta`, `asdf` тощо). Каналам WhatsApp + Telegram потрібен Node, а шляхи менеджера версій можуть ламатися після оновлень, оскільки служба не завантажує ініціалізацію вашої оболонки. Doctor пропонує мігрувати на системну інсталяцію Node, коли вона доступна (Homebrew/apt/choco).
|
||||
|
||||
Нововстановлені або відновлені macOS LaunchAgents використовують канонічний системний PATH (`/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin`) замість копіювання PATH інтерактивної оболонки, тому Volta, asdf, fnm, pnpm та інші каталоги менеджерів версій не змінюють, який Node розв’язують дочірні процеси. Служби Linux і далі зберігають явні корені середовища (`NVM_DIR`, `FNM_DIR`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `BUN_INSTALL`, `PNPM_HOME`) і стабільні каталоги user-bin, але вгадані резервні каталоги менеджерів версій записуються до PATH служби лише тоді, коли ці каталоги існують на диску.
|
||||
Нововстановлені або відновлені macOS LaunchAgents використовують канонічний системний PATH (`/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin`) замість копіювання PATH інтерактивної оболонки, тому каталоги Volta, asdf, fnm, pnpm та інших менеджерів версій не змінюють, який Node розв’язують дочірні процеси. Служби Linux і надалі зберігають явні корені середовища (`NVM_DIR`, `FNM_DIR`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `BUN_INSTALL`, `PNPM_HOME`) і стабільні користувацькі bin-каталоги, але припущені fallback-каталоги менеджерів версій записуються до PATH служби лише тоді, коли ці каталоги існують на диску.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="18. Запис конфігурації + метадані майстра">
|
||||
Doctor зберігає будь-які зміни конфігурації та ставить мітку метаданих майстра, щоб зафіксувати запуск doctor.
|
||||
Doctor зберігає всі зміни конфігурації та ставить мітку метаданих майстра, щоб зафіксувати запуск doctor.
|
||||
</Accordion>
|
||||
<Accordion title="19. Поради щодо робочої області (резервна копія + система пам’яті)">
|
||||
Doctor пропонує систему пам’яті робочої області, коли її немає, і виводить пораду щодо резервної копії, якщо робоча область ще не перебуває під git.
|
||||
<Accordion title="19. Поради щодо робочого простору (резервна копія + система пам’яті)">
|
||||
Doctor пропонує систему пам’яті робочого простору, коли її немає, і виводить пораду щодо резервного копіювання, якщо робочий простір ще не перебуває під git.
|
||||
|
||||
Повний посібник зі структури робочої області та резервного копіювання git (рекомендовано приватний GitHub або GitLab) див. у [/concepts/agent-workspace](/uk/concepts/agent-workspace).
|
||||
Див. [/concepts/agent-workspace](/uk/concepts/agent-workspace) для повного посібника зі структури робочого простору й резервного копіювання git (рекомендовано приватний GitHub або GitLab).
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user