From b5d4dbadfe418be612f82081a709bd27984f03d4 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Fri, 1 May 2026 23:12:46 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/channels/access-groups.md | 189 ++++++ docs/uk/channels/discord.md | 484 ++++++++-------- docs/uk/channels/groups.md | 219 +++---- docs/uk/channels/pairing.md | 141 ++--- docs/uk/ci.md | 372 ++++++------ docs/uk/reference/RELEASING.md | 580 ++++++++++--------- docs/uk/reference/full-release-validation.md | 195 ++++--- 7 files changed, 1205 insertions(+), 975 deletions(-) create mode 100644 docs/uk/channels/access-groups.md diff --git a/docs/uk/channels/access-groups.md b/docs/uk/channels/access-groups.md new file mode 100644 index 000000000..f56710550 --- /dev/null +++ b/docs/uk/channels/access-groups.md @@ -0,0 +1,189 @@ +--- +read_when: + - Налаштування того самого списку дозволених елементів для кількох каналів повідомлень + - Правила доступу відправників до спільного доступу в особистих повідомленнях і групах + - Перегляд контролю доступу до каналів повідомлень +summary: Багаторазові списки дозволених відправників для каналів повідомлень +title: Групи доступу +x-i18n: + generated_at: "2026-05-01T23:10:05Z" + model: gpt-5.5 + provider: openai + source_hash: fc7bc1d4fb80e5c5d4e72b190d49821aa93ced575eafcf89864ac800e8558f94 + source_path: channels/access-groups.md + workflow: 16 +--- + +Групи доступу — це іменовані списки відправників, які ви визначаєте один раз і на які посилаєтеся з allowlist каналів через `accessGroup:`. + +Використовуйте їх, коли тих самих людей потрібно дозволити в кількох каналах повідомлень або коли один довірений набір має застосовуватися і до авторизації відправників у DM, і до груп. + +Групи доступу самі по собі не надають доступу. Група має значення лише тоді, коли поле allowlist посилається на неї. + +## Статичні групи відправників повідомлень + +Статичні групи відправників використовують `type: "message.senders"`. + +```json5 +{ + accessGroups: { + operators: { + type: "message.senders", + members: { + "*": ["global-owner-id"], + discord: ["discord:123456789012345678"], + telegram: ["987654321"], + whatsapp: ["+15551234567"], + }, + }, + }, +} +``` + +Списки учасників індексуються за id каналу повідомлень: + +| Ключ | Значення | +| ---------- | ----------------------------------------------------------------------- | +| `"*"` | Спільні записи, які перевіряються для кожного каналу повідомлень, що посилається на групу. | +| `discord` | Записи, які перевіряються лише для зіставлення allowlist Discord. | +| `telegram` | Записи, які перевіряються лише для зіставлення allowlist Telegram. | +| `whatsapp` | Записи, які перевіряються лише для зіставлення allowlist WhatsApp. | + +Записи зіставляються зі звичайними правилами `allowFrom` цільового каналу. OpenClaw не перекладає id відправників між каналами. Якщо Alice має id Telegram і id Discord, укажіть обидва id під відповідними ключами. + +## Посилання на групи з allowlist + +Посилайтеся на групу через `accessGroup:` будь-де, де шлях каналу повідомлень підтримує allowlist відправників. + +Приклад allowlist для DM: + +```json5 +{ + accessGroups: { + operators: { + type: "message.senders", + members: { + discord: ["discord:123456789012345678"], + telegram: ["987654321"], + }, + }, + }, + channels: { + discord: { + dmPolicy: "allowlist", + allowFrom: ["accessGroup:operators"], + }, + telegram: { + dmPolicy: "allowlist", + allowFrom: ["accessGroup:operators"], + }, + }, +} +``` + +Приклад allowlist відправників групи: + +```json5 +{ + accessGroups: { + oncall: { + type: "message.senders", + members: { + whatsapp: ["+15551234567"], + googlechat: ["users/1234567890"], + }, + }, + }, + channels: { + whatsapp: { + groupPolicy: "allowlist", + groupAllowFrom: ["accessGroup:oncall"], + }, + googlechat: { + spaces: { + "spaces/AAA": { + users: ["accessGroup:oncall"], + }, + }, + }, + }, +} +``` + +Ви можете поєднувати групи й прямі записи: + +```json5 +{ + channels: { + discord: { + dmPolicy: "allowlist", + allowFrom: ["accessGroup:operators", "discord:123456789012345678"], + }, + }, +} +``` + +## Підтримувані шляхи каналів повідомлень + +Групи доступу доступні в спільних шляхах авторизації каналів повідомлень, зокрема: + +- allowlist відправників DM, як-от `channels..allowFrom` +- allowlist відправників груп, як-от `channels..groupAllowFrom` +- специфічні для каналу allowlist відправників на рівні окремої кімнати, які використовують ті самі правила зіставлення відправників +- шляхи авторизації команд, які повторно використовують allowlist відправників каналів повідомлень + +Підтримка каналу залежить від того, чи цей канал підключено через спільні допоміжні засоби авторизації відправників OpenClaw. Поточна вбудована підтримка охоплює Discord, Google Chat, Nostr, WhatsApp, Zalo і Zalo Personal. Статичні групи `message.senders` спроєктовані як незалежні від каналу, тож нові канали повідомлень мають підтримувати їх, використовуючи спільні допоміжні засоби plugin SDK замість власного розгортання allowlist. + +## Аудиторії каналів Discord + +Discord також підтримує динамічний тип групи доступу: + +```json5 +{ + accessGroups: { + maintainers: { + type: "discord.channelAudience", + guildId: "1456350064065904867", + channelId: "1456744319972282449", + membership: "canViewChannel", + }, + }, + channels: { + discord: { + dmPolicy: "allowlist", + allowFrom: ["accessGroup:maintainers"], + }, + }, +} +``` + +`discord.channelAudience` означає: "дозволити відправників DM Discord, які наразі можуть переглядати цей канал guild." OpenClaw визначає відправника через Discord під час авторизації та застосовує правила дозволу Discord `ViewChannel`. + +Використовуйте це, коли канал Discord уже є джерелом істини для команди, наприклад `#maintainers` або `#on-call`. + +Вимоги та поведінка в разі помилки: + +- Боту потрібен доступ до guild і каналу. +- Боту потрібен **Server Members Intent** у Discord Developer Portal. +- Група доступу не надає доступ, коли Discord повертає `Missing Access`, відправника неможливо визначити як учасника guild або канал належить іншому guild. + +Більше прикладів, специфічних для Discord: [Контроль доступу Discord](/uk/channels/discord#access-control-and-routing) + +## Нотатки щодо безпеки + +- Групи доступу — це псевдоніми allowlist, а не ролі. Вони самі по собі не створюють власників, не схвалюють запити на сполучення й не надають дозволи на інструменти. +- `dmPolicy: "open"` усе одно вимагає `"*"` в ефективному allowlist DM. Посилання на групу доступу не є тим самим, що публічний доступ. +- Відсутні назви груп не надають доступ. Якщо `allowFrom` містить `accessGroup:operators`, а `accessGroups.operators` відсутній, цей запис нікого не авторизує. +- Зберігайте id каналів стабільними. Надавайте перевагу числовим/user id замість відображуваних імен, коли канал підтримує обидва варіанти. + +## Усунення несправностей + +Якщо відправник має збігатися, але його заблоковано: + +1. Переконайтеся, що поле allowlist містить точне посилання `accessGroup:`. +2. Переконайтеся, що `accessGroups..type` правильний. +3. Переконайтеся, що id відправника вказано під відповідним ключем каналу або під `"*"`. +4. Переконайтеся, що запис використовує звичайний синтаксис allowlist цього каналу. +5. Для аудиторій каналів Discord переконайтеся, що бот бачить канал guild і має ввімкнений Server Members Intent. + +Запустіть `openclaw doctor` після редагування конфігурації контролю доступу. Він виявляє багато недійсних комбінацій allowlist і політик ще до виконання. diff --git a/docs/uk/channels/discord.md b/docs/uk/channels/discord.md index ee50dd902..72eecdcec 100644 --- a/docs/uk/channels/discord.md +++ b/docs/uk/channels/discord.md @@ -1,22 +1,22 @@ --- read_when: - Робота над функціями каналу Discord -summary: Стан підтримки бота Discord, можливості та конфігурація +summary: Статус підтримки бота Discord, можливості та конфігурація title: Discord x-i18n: - generated_at: "2026-05-01T22:59:34Z" + generated_at: "2026-05-01T23:09:45Z" model: gpt-5.5 provider: openai - source_hash: 6bd33cbe350f4cee90e63334797675d29d2d62efdce9a3eecc29666e04d9dedb + source_hash: 0d87dfc4cbebb2cbf89d92dc2eb55903ada60a390f92c1e1817d67baada87669 source_path: channels/discord.md workflow: 16 --- -Готово для приватних повідомлень і каналів гільдій через офіційний Discord Gateway. +Готово для DM і каналів гільдій через офіційний Discord Gateway. - - Приватні повідомлення Discord за замовчуванням переходять у режим сполучення. + + Discord DM за замовчуванням працюють у режимі створення пари. Нативна поведінка команд і каталог команд. @@ -28,13 +28,13 @@ x-i18n: ## Швидке налаштування -Вам потрібно створити новий застосунок із ботом, додати бота на свій сервер і сполучити його з OpenClaw. Рекомендуємо додати бота на власний приватний сервер. Якщо у вас його ще немає, [спершу створіть його](https://support.discord.com/hc/en-us/articles/204849977-How-do-I-create-a-server) (виберіть **Create My Own > For me and my friends**). +Вам потрібно створити нову програму з ботом, додати бота на свій сервер і створити для нього пару з OpenClaw. Рекомендуємо додати бота на власний приватний сервер. Якщо у вас його ще немає, [спершу створіть його](https://support.discord.com/hc/en-us/articles/204849977-How-do-I-create-a-server) (виберіть **Create My Own > For me and my friends**). - - Перейдіть до [Discord Developer Portal](https://discord.com/developers/applications) і натисніть **New Application**. Назвіть його, наприклад, "OpenClaw". + + Перейдіть до [Discord Developer Portal](https://discord.com/developers/applications) і натисніть **New Application**. Назвіть її, наприклад, "OpenClaw". - Натисніть **Bot** на бічній панелі. Установіть **Username** так, як ви називаєте свого агента OpenClaw. + Натисніть **Bot** на бічній панелі. Установіть **Username** на назву, якою ви називаєте свого агента OpenClaw. @@ -51,14 +51,14 @@ x-i18n: Прокрутіть назад угору на сторінці **Bot** і натисніть **Reset Token**. - Попри назву, це створює ваш перший токен — нічого насправді не "скидається". + Попри назву, це створює ваш перший токен — нічого не "скидається". - Скопіюйте токен і збережіть його десь. Це ваш **Bot Token**, і він знадобиться вам незабаром. + Скопіюйте токен і збережіть його десь. Це ваш **Bot Token**, і він невдовзі знадобиться. - + Натисніть **OAuth2** на бічній панелі. Ви згенеруєте URL запрошення з потрібними дозволами, щоб додати бота на свій сервер. Прокрутіть униз до **OAuth2 URL Generator** і ввімкніть: @@ -66,42 +66,42 @@ x-i18n: - `bot` - `applications.commands` - Нижче з’явиться розділ **Bot Permissions**. Увімкніть щонайменше: + Нижче з’явиться розділ **Bot Permissions**. Увімкніть принаймні: - **Загальні дозволи** + **General Permissions** - Перегляд каналів - **Текстові дозволи** + **Text Permissions** - Надсилання повідомлень - Читання історії повідомлень - Вбудовування посилань - Прикріплення файлів - Додавання реакцій (необов’язково) - Це базовий набір для звичайних текстових каналів. Якщо ви плануєте публікувати в тредах Discord, зокрема в робочих процесах форумів або медіаканалів, які створюють чи продовжують тред, також увімкніть **Send Messages in Threads**. - Скопіюйте згенерований URL унизу, вставте його у браузер, виберіть свій сервер і натисніть **Continue**, щоб підключити. Тепер ви маєте бачити свого бота на сервері Discord. + Це базовий набір для звичайних текстових каналів. Якщо ви плануєте публікувати в тредах Discord, зокрема у сценаріях форумних або медіаканалів, які створюють або продовжують тред, також увімкніть **Send Messages in Threads**. + Скопіюйте згенерований URL унизу, вставте його у браузер, виберіть свій сервер і натисніть **Continue**, щоб підключити. Тепер ви маєте побачити свого бота на сервері Discord. - У застосунку Discord потрібно ввімкнути Developer Mode, щоб копіювати внутрішні ID. + Повернувшись у програму Discord, потрібно ввімкнути Developer Mode, щоб мати змогу копіювати внутрішні ID. 1. Натисніть **User Settings** (іконка шестерні поруч із вашим аватаром) → **Advanced** → увімкніть **Developer Mode** - 2. Натисніть правою кнопкою миші **іконку сервера** на бічній панелі → **Copy Server ID** - 3. Натисніть правою кнопкою миші **власний аватар** → **Copy User ID** + 2. Клацніть правою кнопкою миші **іконку сервера** на бічній панелі → **Copy Server ID** + 3. Клацніть правою кнопкою миші **власний аватар** → **Copy User ID** - Збережіть свої **Server ID** і **User ID** поруч із Bot Token — на наступному кроці ви надішлете всі три значення в OpenClaw. + Збережіть свої **Server ID** і **User ID** поруч із Bot Token — на наступному кроці ви надішлете всі три до OpenClaw. - - Щоб сполучення працювало, Discord має дозволити вашому боту надсилати вам приватні повідомлення. Натисніть правою кнопкою миші **іконку сервера** → **Privacy Settings** → увімкніть **Direct Messages**. + + Щоб створення пари працювало, Discord має дозволяти вашому боту надсилати вам DM. Клацніть правою кнопкою миші **іконку сервера** → **Privacy Settings** → увімкніть **Direct Messages**. - Це дозволяє учасникам сервера (зокрема ботам) надсилати вам приватні повідомлення. Залиште це ввімкненим, якщо хочете використовувати приватні повідомлення Discord з OpenClaw. Якщо ви плануєте використовувати лише канали гільдії, можете вимкнути приватні повідомлення після сполучення. + Це дозволяє учасникам сервера (включно з ботами) надсилати вам DM. Залиште це ввімкненим, якщо хочете використовувати Discord DM з OpenClaw. Якщо ви плануєте використовувати лише канали гільдії, можете вимкнути DM після створення пари. - - Токен вашого Discord-бота є секретом (як пароль). Задайте його на машині, де працює OpenClaw, перед тим як писати своєму агенту. + + Токен вашого Discord-бота є секретом (як пароль). Задайте його на машині, де працює OpenClaw, перш ніж писати своєму агенту. ```bash export DISCORD_BOT_TOKEN="YOUR_BOT_TOKEN" @@ -120,19 +120,19 @@ openclaw config patch --file ./discord.patch.json5 openclaw gateway ``` - Якщо OpenClaw уже працює як фонова служба, перезапустіть його через застосунок OpenClaw для Mac або зупинивши й повторно запустивши процес `openclaw gateway run`. + Якщо OpenClaw уже працює як фонова служба, перезапустіть його через програму OpenClaw для Mac або зупинивши й знову запустивши процес `openclaw gateway run`. Для встановлень керованої служби запустіть `openclaw gateway install` з оболонки, де присутній `DISCORD_BOT_TOKEN`, або збережіть змінну в `~/.openclaw/.env`, щоб служба могла розв’язати env SecretRef після перезапуску. - Якщо ваш хост заблокований або обмежений Discord під час стартового пошуку застосунку, задайте ID застосунку/клієнта Discord з Developer Portal, щоб запуск міг пропустити цей REST-виклик. Використовуйте `channels.discord.applicationId` для облікового запису за замовчуванням або `channels.discord.accounts..applicationId`, коли запускаєте кілька ботів Discord. + Якщо ваш хост заблокований або обмежений за частотою запитів під час стартового пошуку програми Discord, задайте ID програми/клієнта Discord з Developer Portal, щоб запуск міг пропустити цей REST-виклик. Використовуйте `channels.discord.applicationId` для облікового запису за замовчуванням або `channels.discord.accounts..applicationId`, коли запускаєте кілька ботів Discord. - + - Поспілкуйтеся зі своїм агентом OpenClaw у будь-якому наявному каналі (наприклад, Telegram) і повідомте йому. Якщо Discord — ваш перший канал, натомість використайте вкладку CLI / config. + Поспілкуйтеся зі своїм агентом OpenClaw у будь-якому наявному каналі (наприклад, Telegram) і повідомте йому. Якщо Discord — ваш перший канал, натомість використовуйте вкладку CLI / config. - > "Я вже задав токен свого Discord-бота в конфігурації. Заверши налаштування Discord з User ID `` і Server ID ``." + > "I already set my Discord bot token in config. Please finish Discord setup with User ID `` and Server ID ``." Якщо ви віддаєте перевагу файловій конфігурації, задайте: @@ -152,15 +152,15 @@ openclaw gateway } ``` - Env-резерв для облікового запису за замовчуванням: + Резервний env для облікового запису за замовчуванням: ```bash DISCORD_BOT_TOKEN=... ``` - Для скриптового або віддаленого налаштування запишіть той самий блок JSON5 за допомогою `openclaw config patch --file ./discord.patch.json5 --dry-run`, а потім повторно запустіть без `--dry-run`. Значення `token` у відкритому тексті підтримуються. Значення SecretRef також підтримуються для `channels.discord.token` через провайдери env/file/exec. Див. [Керування секретами](/uk/gateway/secrets). + Для скриптового або віддаленого налаштування запишіть той самий блок JSON5 за допомогою `openclaw config patch --file ./discord.patch.json5 --dry-run`, а потім запустіть повторно без `--dry-run`. Значення `token` у відкритому тексті підтримуються. Значення SecretRef також підтримуються для `channels.discord.token` через провайдери env/file/exec. Див. [Керування секретами](/uk/gateway/secrets). - Для кількох Discord-ботів зберігайте токен кожного бота та ID застосунку в його обліковому записі. Верхньорівневий `channels.discord.applicationId` успадковується обліковими записами, тому задавайте його там лише тоді, коли кожен обліковий запис має використовувати той самий ID застосунку. + Для кількох ботів Discord зберігайте токен кожного бота та ID програми в його обліковому записі. Верхньорівневий `channels.discord.applicationId` успадковується обліковими записами, тому задавайте його там лише тоді, коли кожен обліковий запис має використовувати той самий ID програми. ```json5 { @@ -187,14 +187,14 @@ DISCORD_BOT_TOKEN=... - - Дочекайтеся запуску Gateway, а потім напишіть боту приватне повідомлення в Discord. Він відповість кодом сполучення. + + Дочекайтеся, доки gateway запрацює, а потім надішліть DM своєму боту в Discord. Він відповість кодом створення пари. - Надішліть код сполучення своєму агенту у вашому наявному каналі: + Надішліть код створення пари своєму агенту в наявному каналі: - > "Схвали цей код сполучення Discord: ``" + > "Approve this Discord pairing code: ``" @@ -206,30 +206,30 @@ openclaw pairing approve discord - Коди сполучення діють 1 годину. + Коди створення пари спливають через 1 годину. - Тепер ви маєте змогу спілкуватися зі своїм агентом у Discord через приватні повідомлення. + Тепер ви маєте змогу спілкуватися зі своїм агентом у Discord через DM. -Розв’язання токенів враховує обліковий запис. Значення токена з конфігурації мають пріоритет над env-резервом. `DISCORD_BOT_TOKEN` використовується лише для облікового запису за замовчуванням. -Якщо два ввімкнені облікові записи Discord розв’язуються до того самого токена бота, OpenClaw запускає лише один монітор Gateway для цього токена. Токен із конфігурації має пріоритет над env-резервом за замовчуванням; інакше перемагає перший увімкнений обліковий запис, а дубльований обліковий запис повідомляється як вимкнений. -Для розширених вихідних викликів (інструмент повідомлень/дії каналу) явний `token` для кожного виклику використовується саме для цього виклику. Це стосується дій надсилання та дій читання/перевірки (наприклад read/search/fetch/thread/pins/permissions). Політика облікового запису та налаштування повторних спроб усе ще беруться з вибраного облікового запису в активному runtime-знімку. +Розв’язання токена враховує обліковий запис. Значення токена з конфігурації мають пріоритет над резервним env. `DISCORD_BOT_TOKEN` використовується лише для облікового запису за замовчуванням. +Якщо два ввімкнені облікові записи Discord розв’язуються в той самий токен бота, OpenClaw запускає лише один gateway monitor для цього токена. Токен із конфігурації має пріоритет над резервним env за замовчуванням; інакше перемагає перший увімкнений обліковий запис, а дубльований обліковий запис повідомляється як вимкнений. +Для розширених вихідних викликів (дії інструмента message/каналу) явний `token` для кожного виклику використовується для цього виклику. Це застосовується до дій надсилання та дій у стилі читання/перевірки (наприклад, read/search/fetch/thread/pins/permissions). Політика облікового запису й налаштування повторних спроб усе одно беруться з вибраного облікового запису в активному знімку runtime. ## Рекомендовано: налаштуйте робочий простір гільдії -Коли приватні повідомлення запрацюють, ви можете налаштувати свій сервер Discord як повноцінний робочий простір, де кожен канал отримує власну сесію агента зі своїм контекстом. Це рекомендовано для приватних серверів, де є лише ви й ваш бот. +Щойно DM запрацюють, ви можете налаштувати свій сервер Discord як повноцінний робочий простір, де кожен канал отримує власну сесію агента з власним контекстом. Це рекомендовано для приватних серверів, де є лише ви та ваш бот. - Це дає змогу вашому агенту відповідати в будь-якому каналі на вашому сервері, а не лише в приватних повідомленнях. + Це дає змогу вашому агенту відповідати в будь-якому каналі на вашому сервері, а не лише в DM. - > "Додай мій Discord Server ID `` до списку дозволених гільдій" + > "Add my Discord Server ID `` to the guild allowlist" @@ -255,13 +255,13 @@ openclaw pairing approve discord - За замовчуванням ваш агент відповідає в каналах гільдії лише тоді, коли його згадали через @mention. Для приватного сервера ви, ймовірно, хочете, щоб він відповідав на кожне повідомлення. + За замовчуванням ваш агент відповідає в каналах гільдії лише коли його @згадують. Для приватного сервера ви, ймовірно, захочете, щоб він відповідав на кожне повідомлення. - У каналах гільдії звичайні фінальні відповіді асистента за замовчуванням залишаються приватними. Видимий вивід Discord потрібно надсилати явно за допомогою інструмента `message`, тому агент може за замовчуванням спостерігати й публікувати лише тоді, коли вирішить, що відповідь у каналі корисна. + У каналах гільдії звичайні фінальні відповіді асистента за замовчуванням залишаються приватними. Видимий вивід Discord потрібно надсилати явно за допомогою інструмента `message`, тож агент може за замовчуванням спостерігати й публікувати лише тоді, коли вирішить, що відповідь у каналі корисна. - > "Дозволь моєму агенту відповідати на цьому сервері без потреби бути згаданим через @mention" + > "Allow my agent to respond on this server without having to be @mentioned" Задайте `requireMention: false` у конфігурації гільдії: @@ -280,7 +280,7 @@ openclaw pairing approve discord } ``` - Щоб відновити застарілі автоматичні фінальні відповіді для групових чатів/кімнат каналів, задайте `messages.groupChat.visibleReplies: "automatic"`. + Щоб відновити застарілі автоматичні фінальні відповіді для групових/канальних кімнат, задайте `messages.groupChat.visibleReplies: "automatic"`. @@ -288,37 +288,37 @@ openclaw pairing approve discord - За замовчуванням довгострокова пам’ять (MEMORY.md) завантажується лише в сесіях приватних повідомлень. Канали гільдії не завантажують MEMORY.md автоматично. + За замовчуванням довготривала пам’ять (MEMORY.md) завантажується лише в DM-сесіях. Канали гільдії не завантажують MEMORY.md автоматично. - > "Коли я ставлю запитання в каналах Discord, використовуй memory_search або memory_get, якщо тобі потрібен довгостроковий контекст із MEMORY.md." + > "When I ask questions in Discord channels, use memory_search or memory_get if you need long-term context from MEMORY.md." - Якщо вам потрібен спільний контекст у кожному каналі, помістіть стабільні інструкції в `AGENTS.md` або `USER.md` (вони впроваджуються в кожну сесію). Зберігайте довгострокові нотатки в `MEMORY.md` і звертайтеся до них за потреби за допомогою інструментів пам’яті. + Якщо вам потрібен спільний контекст у кожному каналі, помістіть стабільні інструкції в `AGENTS.md` або `USER.md` (вони впроваджуються в кожну сесію). Зберігайте довготривалі нотатки в `MEMORY.md` і звертайтеся до них за потреби за допомогою інструментів пам’яті. -Тепер створіть кілька каналів на своєму сервері Discord і почніть спілкуватися. Ваш агент може бачити назву каналу, а кожен канал отримує власну ізольовану сесію — тож ви можете налаштувати `#coding`, `#home`, `#research` або будь-що, що пасує вашому робочому процесу. +Тепер створіть кілька каналів на своєму сервері Discord і почніть спілкування. Ваш агент бачить назву каналу, і кожен канал отримує власну ізольовану сесію — тож ви можете налаштувати `#coding`, `#home`, `#research` або будь-що, що підходить вашому робочому процесу. -## Runtime-модель +## Модель runtime -- Gateway керує підключенням до Discord. -- Маршрутизація відповідей детермінована: вхідні відповіді Discord повертаються до Discord. +- Gateway володіє з’єднанням Discord. +- Маршрутизація відповідей є детермінованою: вхідні відповіді Discord повертаються до Discord. - Метадані гільдії/каналу Discord додаються до підказки моделі як ненадійний - контекст, а не як видимий користувачу префікс відповіді. Якщо модель копіює цю обгортку - назад, OpenClaw вилучає скопійовані метадані з вихідних відповідей і з + контекст, а не як видимий користувачу префікс відповіді. Якщо модель скопіює цей конверт + назад, OpenClaw вилучить скопійовані метадані з вихідних відповідей і з майбутнього контексту повторного відтворення. -- За замовчуванням (`session.dmScope=main`) прямі чати спільно використовують основну сесію агента (`agent:main:main`). -- Канали гільдій мають ізольовані ключі сесій (`agent::discord:channel:`). +- За замовчуванням (`session.dmScope=main`) прямі чати спільно використовують головну сесію агента (`agent:main:main`). +- Канали гільдій ізольовані ключами сесій (`agent::discord:channel:`). - Групові DM за замовчуванням ігноруються (`channels.discord.dm.groupEnabled=false`). -- Нативні slash-команди виконуються в ізольованих командних сесіях (`agent::discord:slash:`), водночас все ще передаючи `CommandTargetSessionKey` до маршрутизованої сесії розмови. -- Доставка текстових оголошень cron/heartbeat у Discord використовує остаточну +- Нативні slash-команди виконуються в ізольованих командних сесіях (`agent::discord:slash:`), але все одно несуть `CommandTargetSessionKey` до маршрутизованої сесії розмови. +- Доставка текстових оголошень cron/heartbeat до Discord використовує фінальну видиму асистенту відповідь один раз. Медіа та структуровані payload компонентів залишаються - багатоповідомними, коли агент видає кілька доставних payload. + багатоповідомними, коли агент генерує кілька придатних до доставки payload. ## Форумні канали @@ -327,14 +327,14 @@ openclaw pairing approve discord - Надішліть повідомлення до батьківського форуму (`channel:`), щоб автоматично створити тред. Заголовок треду використовує перший непорожній рядок вашого повідомлення. - Використайте `openclaw message thread create`, щоб створити тред напряму. Не передавайте `--message-id` для форумних каналів. -Приклад: надішліть до батьківського форуму, щоб створити тред +Приклад: надіслати до батьківського форуму, щоб створити тред ```bash openclaw message send --channel discord --target channel: \ --message "Topic title\nBody of the post" ``` -Приклад: створіть форумний тред явно +Приклад: явно створити форумний тред ```bash openclaw message thread create --channel discord --target channel: \ @@ -345,7 +345,7 @@ openclaw message thread create --channel discord --target channel: \ ## Інтерактивні компоненти -OpenClaw підтримує контейнери компонентів Discord v2 для повідомлень агента. Використовуйте інструмент повідомлень із payload `components`. Результати взаємодії маршрутизуються назад до агента як звичайні вхідні повідомлення та дотримуються наявних налаштувань Discord `replyToMode`. +OpenClaw підтримує контейнери Discord components v2 для повідомлень агента. Використовуйте інструмент повідомлень із payload `components`. Результати взаємодії маршрутизуються назад до агента як звичайні вхідні повідомлення та дотримуються наявних налаштувань Discord `replyToMode`. Підтримувані блоки: @@ -353,11 +353,11 @@ OpenClaw підтримує контейнери компонентів Discord - Рядки дій дозволяють до 5 кнопок або одне меню вибору - Типи вибору: `string`, `user`, `role`, `mentionable`, `channel` -За замовчуванням компоненти одноразові. Установіть `components.reusable=true`, щоб дозволити багаторазове використання кнопок, виборів і форм до завершення їхнього строку дії. +За замовчуванням компоненти одноразові. Установіть `components.reusable=true`, щоб кнопки, меню вибору та форми можна було використовувати багато разів, доки не спливе їхній термін дії. -Щоб обмежити, хто може натиснути кнопку, установіть `allowedUsers` на цій кнопці (ID користувачів Discord, теги або `*`). Коли це налаштовано, користувачі без збігу отримують тимчасову відмову. +Щоб обмежити, хто може натиснути кнопку, установіть `allowedUsers` для цієї кнопки (ID користувачів Discord, теги або `*`). Коли налаштовано, користувачі, які не збігаються, отримують ефемерну відмову. -Slash-команди `/model` і `/models` відкривають інтерактивний вибір моделі з випадними списками провайдера, моделі та сумісного runtime, а також кроком Submit. `/models add` застаріла й тепер повертає повідомлення про застарілість замість реєстрації моделей із чату. Відповідь вибору тимчасова, і користуватися нею може лише користувач, який її викликав. +Slash-команди `/model` і `/models` відкривають інтерактивний вибір моделі з випадаючими списками провайдера, моделі та сумісного runtime, а також кроком Submit. `/models add` застаріла й тепер повертає повідомлення про застарілість замість реєстрації моделей із чату. Відповідь вибору є ефемерною, і використовувати її може лише користувач, який викликав команду. Вкладення файлів: @@ -367,7 +367,7 @@ Slash-команди `/model` і `/models` відкривають інтерак Модальні форми: -- Додайте `components.modal` із до 5 полями +- Додайте `components.modal` із кількістю полів до 5 - Типи полів: `text`, `checkbox`, `radio`, `select`, `role-select`, `user-select` - OpenClaw автоматично додає кнопку запуску @@ -428,38 +428,38 @@ Slash-команди `/model` і `/models` відкривають інтерак ## Контроль доступу та маршрутизація - - `channels.discord.dmPolicy` керує доступом DM. `channels.discord.allowFrom` є канонічним allowlist DM. + + `channels.discord.dmPolicy` керує доступом до DM. `channels.discord.allowFrom` є канонічним allowlist для DM. - `pairing` (за замовчуванням) - `allowlist` - - `open` (потребує, щоб `channels.discord.allowFrom` містив `"*"`) + - `open` (вимагає, щоб `channels.discord.allowFrom` містив `"*"`) - `disabled` - Якщо політика DM не відкрита, невідомі користувачі блокуються (або отримують запит на pairing у режимі `pairing`). + Якщо політика DM не є відкритою, невідомі користувачі блокуються (або їм пропонується сполучення в режимі `pairing`). - Пріоритет для кількох облікових записів: + Пріоритетність для кількох облікових записів: - `channels.discord.accounts.default.allowFrom` застосовується лише до облікового запису `default`. - Для одного облікового запису `allowFrom` має пріоритет над застарілим `dm.allowFrom`. - Іменовані облікові записи успадковують `channels.discord.allowFrom`, коли їхні власні `allowFrom` і застарілий `dm.allowFrom` не задані. - Іменовані облікові записи не успадковують `channels.discord.accounts.default.allowFrom`. - Застарілі `channels.discord.dm.policy` і `channels.discord.dm.allowFrom` усе ще зчитуються для сумісності. `openclaw doctor --fix` мігрує їх до `dmPolicy` і `allowFrom`, коли це можна зробити без зміни доступу. + Застарілі `channels.discord.dm.policy` і `channels.discord.dm.allowFrom` все ще читаються для сумісності. `openclaw doctor --fix` мігрує їх до `dmPolicy` і `allowFrom`, коли може зробити це без зміни доступу. Формат цілі DM для доставки: - `user:` - згадка `<@id>` - Голі числові ID зазвичай розв’язуються як ID каналів, коли активний типовий канал, але ID, зазначені в ефективному DM `allowFrom` облікового запису, розглядаються як цілі user DM для сумісності. + Голі числові ID зазвичай розпізнаються як ID каналів, коли активне значення каналу за замовчуванням, але ID, перелічені в ефективному DM `allowFrom` облікового запису, розглядаються як цілі DM користувача для сумісності. - + DM Discord можуть використовувати динамічні записи `accessGroup:` у `channels.discord.allowFrom`. - Імена груп доступу спільні для каналів повідомлень. Використовуйте `type: "message.senders"` для статичної групи, учасники якої виражені у звичайному синтаксисі `allowFrom` кожного каналу, або `type: "discord.channelAudience"`, коли поточна аудиторія `ViewChannel` каналу Discord має динамічно визначати членство. + Назви груп доступу спільні для каналів повідомлень. Використовуйте `type: "message.senders"` для статичної групи, учасники якої виражені у звичайному синтаксисі `allowFrom` кожного каналу, або `type: "discord.channelAudience"`, коли поточна аудиторія `ViewChannel` каналу Discord має динамічно визначати членство. Спільну поведінку груп доступу задокументовано тут: [Групи доступу](/uk/channels/access-groups). ```json5 { @@ -482,9 +482,9 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Текстовий канал Discord не має окремого списку учасників. `type: "discord.channelAudience"` моделює членство так: відправник DM є учасником налаштованої гільдії та наразі має ефективний дозвіл `ViewChannel` на налаштованому каналі після застосування ролей і перевизначень каналу. + Текстовий канал Discord не має окремого списку учасників. `type: "discord.channelAudience"` моделює членство так: відправник DM є учасником налаштованої гільдії та наразі має ефективний дозвіл `ViewChannel` на налаштований канал після застосування ролей і перевизначень каналу. - Приклад: дозвольте будь-кому, хто бачить `#maintainers`, надсилати DM боту, залишаючи DM закритими для всіх інших. + Приклад: дозволити всім, хто може бачити `#maintainers`, надсилати DM боту, залишаючи DM закритими для всіх інших. ```json5 { @@ -505,7 +505,7 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Ви можете змішувати динамічні й статичні записи: + Ви можете змішувати динамічні та статичні записи: ```json5 { @@ -525,28 +525,28 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Пошуки закривають доступ у разі помилки. Якщо Discord повертає `Missing Access`, пошук учасника завершується помилкою або канал належить іншій гільдії, відправник DM вважається неавторизованим. + Пошуки закривають доступ у разі помилки. Якщо Discord повертає `Missing Access`, пошук учасника завершується невдало або канал належить до іншої гільдії, відправник DM вважається неавторизованим. - Увімкніть **Server Members Intent** у Discord Developer Portal для бота, коли використовуєте групи доступу на основі аудиторії каналу. DM не містять стану учасника гільдії, тому OpenClaw розв’язує учасника через Discord REST під час авторизації. + Увімкніть **Server Members Intent** у Discord Developer Portal для бота, коли використовуєте групи доступу аудиторії каналу. DM не містять стан учасника гільдії, тому OpenClaw розв’язує учасника через Discord REST під час авторизації. - + Обробкою гільдій керує `channels.discord.groupPolicy`: - `open` - `allowlist` - `disabled` - Безпечний базовий рівень, коли існує `channels.discord`, — `allowlist`. + Безпечна базова лінія, коли існує `channels.discord`, — `allowlist`. Поведінка `allowlist`: - - гільдія має збігатися з `channels.discord.guilds` (перевага надається `id`, slug приймається) - - необов’язкові allowlist відправників: `users` (рекомендовано стабільні ID) і `roles` (лише ID ролей); якщо налаштовано будь-який із них, відправники дозволені, коли вони збігаються з `users` АБО `roles` - - прямий збіг імені/тега за замовчуванням вимкнено; вмикайте `channels.discord.dangerouslyAllowNameMatching: true` лише як режим сумісності на крайній випадок - - імена/теги підтримуються для `users`, але ID безпечніші; `openclaw security audit` попереджає, коли використовуються записи імен/тегів - - якщо гільдія має налаштовані `channels`, канали поза списком заборонені + - гільдія має збігатися з `channels.discord.guilds` (переважно `id`, slug приймається) + - необов’язкові allowlist відправників: `users` (рекомендовано стабільні ID) і `roles` (лише ID ролей); якщо будь-який із них налаштовано, відправники дозволені, коли вони збігаються з `users` АБО `roles` + - пряме зіставлення імен/тегів вимкнено за замовчуванням; увімкніть `channels.discord.dangerouslyAllowNameMatching: true` лише як режим сумісності для аварійного випадку + - імена/теги підтримуються для `users`, але ID безпечніші; `openclaw security audit` попереджає, коли використовуються записи з іменами/тегами + - якщо гільдія має налаштовані `channels`, канали не зі списку відхиляються - якщо гільдія не має блока `channels`, дозволені всі канали в цій allowlisted гільдії Приклад: @@ -573,33 +573,33 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Якщо ви лише встановили `DISCORD_BOT_TOKEN` і не створили блок `channels.discord`, runtime fallback — `groupPolicy="allowlist"` (із попередженням у логах), навіть якщо `channels.defaults.groupPolicy` дорівнює `open`. + Якщо ви встановили лише `DISCORD_BOT_TOKEN` і не створили блок `channels.discord`, runtime fallback — `groupPolicy="allowlist"` (із попередженням у логах), навіть якщо `channels.defaults.groupPolicy` — `open`. - - Повідомлення гільдії за замовчуванням обмежені згадками. + + Повідомлення гільдій за замовчуванням обмежені згадками. - Виявлення згадок включає: + Виявлення згадок охоплює: - явну згадку бота - налаштовані шаблони згадок (`agents.list[].groupChat.mentionPatterns`, fallback `messages.groupChat.mentionPatterns`) - неявну поведінку відповіді боту в підтримуваних випадках `requireMention` налаштовується для кожної гільдії/каналу (`channels.discord.guilds...`). - `ignoreOtherMentions` необов’язково відкидає повідомлення, які згадують іншого користувача/роль, але не бота (за винятком @everyone/@here). + `ignoreOtherMentions` необов’язково відкидає повідомлення, які згадують іншого користувача/роль, але не бота (крім @everyone/@here). Групові DM: - за замовчуванням: ігноруються (`dm.groupEnabled=false`) - - необов’язковий allowlist через `dm.groupChannels` (ID каналів або slug) + - необов’язковий allowlist через `dm.groupChannels` (ID каналів або slugs) ### Маршрутизація агентів на основі ролей -Використовуйте `bindings[].match.roles`, щоб маршрутизувати учасників гільдії Discord до різних агентів за ID ролі. Прив’язки на основі ролей приймають лише ID ролей і оцінюються після прив’язок peer або parent-peer та перед прив’язками лише за гільдією. Якщо прив’язка також задає інші поля збігу (наприклад `peer` + `guildId` + `roles`), усі налаштовані поля мають збігатися. +Використовуйте `bindings[].match.roles`, щоб маршрутизувати учасників гільдії Discord до різних агентів за ID ролі. Прив’язки на основі ролей приймають лише ID ролей і оцінюються після прив’язок peer або parent-peer та перед прив’язками лише для гільдії. Якщо прив’язка також задає інші поля зіставлення (наприклад, `peer` + `guildId` + `roles`), усі налаштовані поля мають збігатися. ```json5 { @@ -625,49 +625,49 @@ Slash-команди `/model` і `/models` відкривають інтерак ## Нативні команди та авторизація команд -- `commands.native` за замовчуванням має значення `"auto"` і ввімкнено для Discord. +- `commands.native` за замовчуванням має значення `"auto"` і ввімкнений для Discord. - Перевизначення для окремого каналу: `channels.discord.commands.native`. - `commands.native=false` явно очищає раніше зареєстровані нативні команди Discord. - Авторизація нативних команд використовує ті самі allowlist/політики Discord, що й звичайна обробка повідомлень. -- Команди все ще можуть бути видимі в UI Discord для користувачів, які не авторизовані; виконання все одно застосовує авторизацію OpenClaw і повертає "не авторизовано". +- Команди можуть усе ще бути видимими в UI Discord для користувачів, які не авторизовані; виконання все одно застосовує авторизацію OpenClaw і повертає "not authorized". -Див. [Slash-команди](/uk/tools/slash-commands) щодо каталогу команд і поведінки. +Див. [Slash-команди](/uk/tools/slash-commands) для каталогу команд і поведінки. -Типові налаштування slash-команд: +Стандартні налаштування slash-команд: - `ephemeral: true` -## Деталі функцій +## Відомості про функції - - Discord підтримує теги відповіді у виводі агента: + + Discord підтримує теги відповідей у виводі агента: - `[[reply_to_current]]` - `[[reply_to:]]` Керується через `channels.discord.replyToMode`: - - `off` (за замовчуванням) + - `off` (стандартно) - `first` - `all` - `batched` - Примітка: `off` вимикає неявне створення гілок відповідей. Явні теги `[[reply_to_*]]` все одно враховуються. - `first` завжди додає неявне посилання нативної відповіді до першого вихідного повідомлення Discord за хід. - `batched` додає неявне посилання нативної відповіді Discord лише тоді, коли - вхідний хід був debounced-пакетом із кількох повідомлень. Це корисно, - коли нативні відповіді потрібні переважно для неоднозначних швидких чатів, а не для кожного + Примітка: `off` вимикає неявне створення ланцюжків відповідей. Явні теги `[[reply_to_*]]` усе одно враховуються. + `first` завжди додає неявне нативне посилання на відповідь до першого вихідного повідомлення Discord для цього ходу. + `batched` додає неявне нативне посилання Discord на відповідь лише тоді, коли + вхідний хід був згрупованою з усуненням брязкоту партією з кількох повідомлень. Це корисно, + коли вам потрібні нативні відповіді переважно для неоднозначних швидких чатів, а не для кожного ходу з одним повідомленням. - Ідентифікатори повідомлень надаються в контексті/історії, щоб агенти могли націлюватися на конкретні повідомлення. + Ідентифікатори повідомлень відображаються в контексті/історії, щоб агенти могли націлюватися на конкретні повідомлення. - OpenClaw може транслювати чернетки відповідей, надсилаючи тимчасове повідомлення й редагуючи його в міру надходження тексту. `channels.discord.streaming` приймає `off` (за замовчуванням) | `partial` | `block` | `progress`. `progress` у Discord відображається як `partial`; `streamMode` є застарілим псевдонімом і автоматично мігрується. + OpenClaw може потоково передавати чернетки відповідей, надсилаючи тимчасове повідомлення й редагуючи його в міру надходження тексту. `channels.discord.streaming` приймає `off` (стандартно) | `partial` | `block` | `progress`. `progress` зіставляється з `partial` у Discord; `streamMode` є застарілим псевдонімом і мігрується автоматично. - Стандартне значення лишається `off`, бо редагування попереднього перегляду в Discord швидко впираються в ліміти частоти, коли кілька ботів або gateways спільно використовують один обліковий запис. + Стандартним лишається `off`, оскільки редагування попереднього перегляду Discord швидко впираються в обмеження швидкості, коли кілька ботів або gateway використовують один обліковий запис. ```json5 { @@ -685,19 +685,19 @@ Slash-команди `/model` і `/models` відкривають інтерак ``` - `partial` редагує одне повідомлення попереднього перегляду в міру надходження токенів. - - `block` надсилає фрагменти розміру чернетки (використовуйте `draftChunk`, щоб налаштувати розмір і точки розбиття, обмежені `textChunkLimit`). - - Медіа, помилки та фінальні відповіді з явною відповіддю скасовують очікувані редагування попереднього перегляду. - - `streaming.preview.toolProgress` (за замовчуванням `true`) керує тим, чи оновлення інструментів/прогресу повторно використовують повідомлення попереднього перегляду. + - `block` випускає фрагменти розміром із чернетку (використовуйте `draftChunk`, щоб налаштувати розмір і точки розриву; значення обмежуються `textChunkLimit`). + - Медіа, помилки та фінальні явні відповіді скасовують очікувані редагування попереднього перегляду. + - `streaming.preview.toolProgress` (стандартно `true`) керує тим, чи оновлення інструментів/прогресу повторно використовують повідомлення попереднього перегляду. - Потоковий попередній перегляд підтримує лише текст; медіавідповіді повертаються до звичайної доставки. Коли потокове передавання `block` явно ввімкнене, OpenClaw пропускає потік попереднього перегляду, щоб уникнути подвійного потокового передавання. + Потоковий попередній перегляд підтримує лише текст; медіавідповіді повертаються до звичайної доставки. Коли потокове передавання `block` явно ввімкнено, OpenClaw пропускає потік попереднього перегляду, щоб уникнути подвійного потокового передавання. - Контекст історії гільдії: + Контекст історії сервера: - - стандартне значення `channels.discord.historyLimit` — `20` - - запасний варіант: `messages.groupChat.historyLimit` + - стандарт `channels.discord.historyLimit` — `20` + - резервне значення: `messages.groupChat.historyLimit` - `0` вимикає Елементи керування історією DM: @@ -707,25 +707,25 @@ Slash-команди `/model` і `/models` відкривають інтерак Поведінка гілок: - - Гілки Discord маршрутизуються як сеанси каналів і успадковують конфігурацію батьківського каналу, якщо її не перевизначено. - - Сеанси гілок успадковують вибір `/model` рівня сеансу з батьківського каналу як резерв лише для моделі; локальні для гілки вибори `/model` усе одно мають пріоритет, а історія транскрипту батьківського каналу не копіюється, якщо не ввімкнене успадкування транскрипту. - - `channels.discord.thread.inheritParent` (за замовчуванням `false`) дозволяє новим автоматичним гілкам ініціалізуватися з батьківського транскрипту. Перевизначення для окремих облікових записів містяться в `channels.discord.accounts..thread.inheritParent`. + - Гілки Discord маршрутизуються як сеанси каналу й успадковують конфігурацію батьківського каналу, якщо її не перевизначено. + - Сеанси гілок успадковують вибір `/model` рівня сеансу з батьківського каналу як резерв лише для моделі; локальні для гілки вибори `/model` усе одно мають пріоритет, а історія транскрипту батьківського каналу не копіюється, якщо не ввімкнено успадкування транскрипту. + - `channels.discord.thread.inheritParent` (стандартно `false`) вмикає для нових автоматичних гілок початкове наповнення з батьківського транскрипту. Перевизначення для окремих облікових записів розміщуються в `channels.discord.accounts..thread.inheritParent`. - Реакції інструмента повідомлень можуть розв’язувати цілі DM `user:`. - `guilds..channels..requireMention: false` зберігається під час резервної активації на етапі відповіді. - Теми каналів інжектуються як **ненадійний** контекст. Списки дозволених користувачів обмежують, хто може запускати агента, але не є повною межею редагування додаткового контексту. + Теми каналів вводяться як **ненадійний** контекст. Списки дозволених визначають, хто може запускати агента, а не є повною межею редагування додаткового контексту. - - Discord може прив’язати гілку до цілі сеансу, щоб наступні повідомлення в цій гілці й надалі маршрутизувалися до того самого сеансу (зокрема сеансів субагентів). + + Discord може прив’язати гілку до цілі сеансу, щоб подальші повідомлення в цій гілці й надалі маршрутизувалися до того самого сеансу (включно із сеансами субагентів). Команди: - `/focus ` прив’язати поточну/нову гілку до цілі субагента/сеансу - `/unfocus` видалити прив’язку поточної гілки - `/agents` показати активні запуски та стан прив’язки - - `/session idle ` переглянути/оновити автоматичне скасування фокуса через неактивність для сфокусованих прив’язок + - `/session idle ` переглянути/оновити автоматичне зняття фокуса за неактивності для сфокусованих прив’язок - `/session max-age ` переглянути/оновити жорсткий максимальний вік для сфокусованих прив’язок Конфігурація: @@ -758,14 +758,14 @@ Slash-команди `/model` і `/models` відкривають інтерак - `channels.discord.threadBindings.*` перевизначає поведінку Discord. - `spawnSubagentSessions` має бути true, щоб автоматично створювати/прив’язувати гілки для `sessions_spawn({ thread: true })`. - `spawnAcpSessions` має бути true, щоб автоматично створювати/прив’язувати гілки для ACP (`/acp spawn ... --thread ...` або `sessions_spawn({ runtime: "acp", thread: true })`). - - Якщо прив’язки гілок вимкнені для облікового запису, `/focus` і пов’язані операції прив’язки гілок недоступні. + - Якщо прив’язки гілок вимкнено для облікового запису, `/focus` і пов’язані операції прив’язки гілок недоступні. Див. [Субагенти](/uk/tools/subagents), [Агенти ACP](/uk/tools/acp-agents) і [Довідник конфігурації](/uk/gateway/configuration-reference). - Для стабільних «завжди ввімкнених» робочих просторів ACP налаштуйте типізовані прив’язки ACP верхнього рівня, націлені на розмови Discord. + Для стабільних «always-on» робочих просторів ACP налаштуйте типізовані прив’язки ACP верхнього рівня, націлені на розмови Discord. Шлях конфігурації: @@ -821,49 +821,49 @@ Slash-команди `/model` і `/models` відкривають інтерак Примітки: - - `/acp spawn codex --bind here` прив’язує поточний канал або гілку на місці й залишає майбутні повідомлення в тому самому сеансі ACP. Повідомлення гілки успадковують прив’язку батьківського каналу. + - `/acp spawn codex --bind here` прив’язує поточний канал або гілку на місці та зберігає майбутні повідомлення в тому самому сеансі ACP. Повідомлення гілки успадковують прив’язку батьківського каналу. - У прив’язаному каналі або гілці `/new` і `/reset` скидають той самий сеанс ACP на місці. Тимчасові прив’язки гілок можуть перевизначати розв’язання цілі, доки активні. - `spawnAcpSessions` потрібен лише тоді, коли OpenClaw має створити/прив’язати дочірню гілку через `--thread auto|here`. - Див. [Агенти ACP](/uk/tools/acp-agents), щоб дізнатися подробиці поведінки прив’язки. + Див. [Агенти ACP](/uk/tools/acp-agents), щоб дізнатися більше про поведінку прив’язок. - Режим сповіщень про реакції для кожної гільдії: + Режим сповіщень про реакції для кожного сервера: - `off` - - `own` (за замовчуванням) + - `own` (стандартно) - `all` - `allowlist` (використовує `guilds..users`) - Події реакцій перетворюються на системні події та приєднуються до маршрутизованого сеансу Discord. + Події реакцій перетворюються на системні події та додаються до маршрутизованого сеансу Discord. - `ackReaction` надсилає emoji підтвердження, поки OpenClaw обробляє вхідне повідомлення. + `ackReaction` надсилає емодзі підтвердження, поки OpenClaw обробляє вхідне повідомлення. Порядок розв’язання: - `channels.discord.accounts..ackReaction` - `channels.discord.ackReaction` - `messages.ackReaction` - - резервний emoji ідентичності агента (`agents.list[].identity.emoji`, інакше "👀") + - резервний емодзі ідентичності агента (`agents.list[].identity.emoji`, інакше "👀") Примітки: - - Discord приймає unicode emoji або назви користувацьких emoji. + - Discord приймає unicode-емодзі або назви власних емодзі. - Використовуйте `""`, щоб вимкнути реакцію для каналу або облікового запису. - Записи конфігурації, ініційовані каналом, увімкнені за замовчуванням. + Записи конфігурації, ініційовані каналом, увімкнені стандартно. - Це впливає на потоки `/config set|unset` (коли командні функції ввімкнені). + Це впливає на потоки `/config set|unset` (коли функції команд увімкнено). - Вимкнути: + Вимкнення: ```json5 { @@ -878,7 +878,7 @@ Slash-команди `/model` і `/models` відкривають інтерак - Маршрутизуйте WebSocket-трафік Gateway Discord і стартові REST-пошуки (ідентифікатор застосунку + розв’язання списку дозволених) через HTTP(S)-проксі з `channels.discord.proxy`. + Маршрутизуйте WebSocket-трафік Discord gateway і стартові REST-пошуки (ID застосунку + розв’язання списку дозволених) через HTTP(S)-проксі з `channels.discord.proxy`. ```json5 { @@ -890,7 +890,7 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Перевизначення для окремого облікового запису: + Перевизначення для облікового запису: ```json5 { @@ -909,7 +909,7 @@ Slash-команди `/model` і `/models` відкривають інтерак - Увімкніть розв’язання PluralKit, щоб зіставляти проксовані повідомлення з ідентичністю учасника системи: + Увімкніть розв’язання PluralKit, щоб зіставляти проксійовані повідомлення з ідентичністю учасника системи: ```json5 { @@ -928,8 +928,8 @@ Slash-команди `/model` і `/models` відкривають інтерак - списки дозволених можуть використовувати `pk:` - відображувані імена учасників зіставляються за назвою/slug лише коли `channels.discord.dangerouslyAllowNameMatching: true` - - пошуки використовують ідентифікатор оригінального повідомлення й обмежені часовим вікном - - якщо пошук не вдається, проксовані повідомлення обробляються як повідомлення ботів і відкидаються, якщо `allowBots=true` не задано + - пошуки використовують ID оригінального повідомлення й обмежені часовим вікном + - якщо пошук не вдався, проксійовані повідомлення вважаються повідомленнями бота й відкидаються, якщо `allowBots=true` не задано @@ -948,7 +948,7 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Приклад активності (користувацький статус є стандартним типом активності): + Приклад активності (власний статус є стандартним типом активності): ```json5 { @@ -961,7 +961,7 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Приклад потокової трансляції: + Приклад потокового передавання: ```json5 { @@ -978,13 +978,13 @@ Slash-команди `/model` і `/models` відкривають інтерак Мапа типів активності: - 0: Грає - - 1: Транслює (потребує `activityUrl`) + - 1: Потокове передавання (потребує `activityUrl`) - 2: Слухає - 3: Дивиться - - 4: Користувацький (використовує текст активності як стан статусу; emoji необов’язковий) + - 4: Власний (використовує текст активності як стан статусу; емодзі необов’язковий) - 5: Змагається - Приклад автоматичної присутності (сигнал стану runtime): + Приклад автоматичної присутності (сигнал справності середовища виконання): ```json5 { @@ -1001,48 +1001,48 @@ Slash-команди `/model` і `/models` відкривають інтерак } ``` - Автоматична присутність відображає доступність runtime на статус Discord: healthy => online, degraded або unknown => idle, exhausted або unavailable => dnd. Необов’язкові перевизначення тексту: + Автоматична присутність зіставляє доступність середовища виконання зі статусом Discord: healthy => online, degraded або unknown => idle, exhausted або unavailable => dnd. Необов’язкові перевизначення тексту: - `autoPresence.healthyText` - `autoPresence.degradedText` - - `autoPresence.exhaustedText` (підтримує placeholder `{reason}`) + - `autoPresence.exhaustedText` (підтримує заповнювач `{reason}`) - Discord підтримує обробку затверджень на основі кнопок у DM і може необов’язково публікувати запити на затвердження у вихідному каналі. + Discord підтримує обробку затверджень за допомогою кнопок у DM і може необов’язково публікувати запити на затвердження у вихідному каналі. Шлях конфігурації: - `channels.discord.execApprovals.enabled` - `channels.discord.execApprovals.approvers` (необов’язково; за можливості повертається до `commands.ownerAllowFrom`) - - `channels.discord.execApprovals.target` (`dm` | `channel` | `both`, за замовчуванням: `dm`) + - `channels.discord.execApprovals.target` (`dm` | `channel` | `both`, стандартно: `dm`) - `agentFilter`, `sessionFilter`, `cleanupAfterResolve` - Discord автоматично вмикає нативні затвердження виконання, коли `enabled` не задано або має значення `"auto"` і можна розв’язати принаймні одного затверджувача — або з `execApprovals.approvers`, або з `commands.ownerAllowFrom`. Discord не виводить затверджувачів виконання з канального `allowFrom`, застарілого `dm.allowFrom` чи `defaultTo` для прямих повідомлень. Задайте `enabled: false`, щоб явно вимкнути Discord як нативний клієнт затверджень. + Discord автоматично вмикає нативні затвердження виконання, коли `enabled` не задано або має значення `"auto"` і можна розв’язати принаймні одного затверджувача — або з `execApprovals.approvers`, або з `commands.ownerAllowFrom`. Discord не виводить затверджувачів виконання з канального `allowFrom`, застарілого `dm.allowFrom` або direct-message `defaultTo`. Задайте `enabled: false`, щоб явно вимкнути Discord як нативний клієнт затвердження. - Для чутливих групових команд лише для власників, як-от `/diagnostics` і `/export-trajectory`, OpenClaw надсилає запити на затвердження та фінальні результати приватно. Спершу він пробує DM Discord, коли власник, що викликає команду, має маршрут власника Discord; якщо він недоступний, OpenClaw повертається до першого доступного маршруту власника з `commands.ownerAllowFrom`, наприклад Telegram. + Для чутливих групових команд лише для власника, як-от `/diagnostics` і `/export-trajectory`, OpenClaw надсилає запити на затвердження та фінальні результати приватно. Спочатку він пробує Discord DM, коли власник, що викликає команду, має маршрут власника Discord; якщо він недоступний, використовується перший доступний маршрут власника з `commands.ownerAllowFrom`, наприклад Telegram. - Коли `target` має значення `channel` або `both`, запит на затвердження видимий у каналі. Кнопки можуть використовувати лише розв’язані затверджувачі; інші користувачі отримують ефемерну відмову. Запити на затвердження містять текст команди, тому вмикайте доставку в канал лише в довірених каналах. Якщо ідентифікатор каналу неможливо вивести з ключа сеансу, OpenClaw повертається до доставки через DM. + Коли `target` має значення `channel` або `both`, запит на схвалення видимий у каналі. Лише визначені схвалювачі можуть використовувати кнопки; інші користувачі отримують ефемерну відмову. Запити на схвалення містять текст команди, тому вмикайте доставку в канал лише в довірених каналах. Якщо ID каналу неможливо отримати з ключа сесії, OpenClaw повертається до доставки через DM. - Discord також відображає спільні кнопки схвалення, які використовуються іншими чат-каналами. Нативний адаптер Discord переважно додає маршрутизацію DM для схвалювачів і розсилання в канали. - Коли ці кнопки присутні, вони є основним UX для схвалень; OpenClaw - має включати ручну команду `/approve` лише тоді, коли результат інструмента повідомляє, що - чат-схвалення недоступні або ручне схвалення є єдиним шляхом. - Якщо нативний runtime схвалень Discord не активний, OpenClaw залишає - локальну детерміновану підказку `/approve ` видимою. Якщо - runtime активний, але нативну картку неможливо доставити жодній цілі, - OpenClaw надсилає резервне сповіщення в тому самому чаті з точною командою `/approve` + Discord також рендерить спільні кнопки схвалення, які використовують інші чат-канали. Нативний адаптер Discord переважно додає маршрутизацію DM для схвалювачів і розсилання в канал. + Коли ці кнопки присутні, вони є основним UX схвалення; OpenClaw + має додавати ручну команду `/approve` лише тоді, коли результат інструмента каже, + що чат-схвалення недоступні або ручне схвалення є єдиним шляхом. + Якщо нативне середовище схвалень Discord не активне, OpenClaw залишає + локальний детермінований запит `/approve ` видимим. Якщо + середовище активне, але нативну картку неможливо доставити жодній цілі, + OpenClaw надсилає резервне сповіщення в той самий чат із точною командою `/approve` з очікуваного схвалення. - Автентифікація Gateway і розв’язання схвалень відповідають спільному контракту клієнта Gateway (`plugin:` ID розв’язуються через `plugin.approval.resolve`; інші ID — через `exec.approval.resolve`). За замовчуванням термін дії схвалень спливає через 30 хвилин. + Автентифікація Gateway і вирішення схвалень дотримуються спільного контракту клієнта Gateway (`plugin:` IDs вирішуються через `plugin.approval.resolve`; інші IDs через `exec.approval.resolve`). Схвалення за замовчуванням спливають через 30 хвилин. - Див. [Схвалення exec](/uk/tools/exec-approvals). + Див. [Схвалення Exec](/uk/tools/exec-approvals). -## Інструменти та шлюзи дій +## Інструменти й шлюзи дій Дії повідомлень Discord охоплюють обмін повідомленнями, адміністрування каналів, модерацію, присутність і дії з метаданими. @@ -1053,25 +1053,25 @@ Slash-команди `/model` і `/models` відкривають інтерак - модерація: `timeout`, `kick`, `ban` - присутність: `setPresence` -Дія `event-create` приймає необов’язковий параметр `image` (URL або локальний шлях до файлу), щоб установити зображення обкладинки запланованої події. +Дія `event-create` приймає необов’язковий параметр `image` (URL або шлях до локального файлу), щоб установити обкладинку запланованої події. Шлюзи дій розміщені в `channels.discord.actions.*`. Поведінка шлюзів за замовчуванням: -| Група дій | За замовчуванням | +| Група дій | За замовчуванням | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- | -| reactions, messages, threads, pins, polls, search, memberInfo, roleInfo, channelInfo, channels, voiceStatus, events, stickers, emojiUploads, stickerUploads, permissions | enabled | -| roles | disabled | -| moderation | disabled | -| presence | disabled | +| reactions, messages, threads, pins, polls, search, memberInfo, roleInfo, channelInfo, channels, voiceStatus, events, stickers, emojiUploads, stickerUploads, permissions | увімкнено | +| roles | вимкнено | +| moderation | вимкнено | +| presence | вимкнено | ## UI Components v2 -OpenClaw використовує Discord components v2 для схвалень exec і маркерів між контекстами. Дії повідомлень Discord також можуть приймати `components` для користувацького UI (розширений сценарій; потребує створення payload компонента через інструмент discord), тоді як застарілі `embeds` залишаються доступними, але не рекомендовані. +OpenClaw використовує components v2 Discord для схвалень exec і маркерів між контекстами. Дії повідомлень Discord також можуть приймати `components` для користувацького UI (розширений сценарій; потребує створення payload компонента через інструмент discord), тоді як застарілі `embeds` залишаються доступними, але не рекомендовані. - `channels.discord.ui.components.accentColor` задає акцентний колір, який використовують контейнери компонентів Discord (hex). -- Для окремого облікового запису задайте через `channels.discord.accounts..ui.components.accentColor`. +- Налаштуйте для кожного облікового запису через `channels.discord.accounts..ui.components.accentColor`. - `embeds` ігноруються, коли присутні components v2. Приклад: @@ -1092,20 +1092,20 @@ OpenClaw використовує Discord components v2 для схвалень ## Голос -Discord має дві окремі голосові поверхні: realtime **голосові канали** (безперервні розмови) і **вкладення голосових повідомлень** (формат попереднього перегляду хвильової форми). Gateway підтримує обидві. +Discord має дві окремі голосові поверхні: голосові канали **реального часу** (безперервні розмови) і **вкладення голосових повідомлень** (формат попереднього перегляду хвилі). Gateway підтримує обидві. ### Голосові канали Контрольний список налаштування: 1. Увімкніть Message Content Intent у Discord Developer Portal. -2. Увімкніть Server Members Intent, коли використовуються списки дозволів ролей/користувачів. +2. Увімкніть Server Members Intent, коли використовуються списки дозволених ролей/користувачів. 3. Запросіть бота зі scopes `bot` і `applications.commands`. 4. Надайте Connect, Speak, Send Messages і Read Message History у цільовому голосовому каналі. 5. Увімкніть нативні команди (`commands.native` або `channels.discord.commands.native`). 6. Налаштуйте `channels.discord.voice`. -Використовуйте `/vc join|leave|status` для керування сесіями. Команда використовує стандартного агента облікового запису та дотримується тих самих правил allowlist і групової політики, що й інші команди Discord. +Використовуйте `/vc join|leave|status`, щоб керувати сесіями. Команда використовує агента за замовчуванням для облікового запису й дотримується тих самих правил списку дозволених і групової політики, що й інші команди Discord. ```bash /vc join channel: @@ -1113,7 +1113,7 @@ Discord має дві окремі голосові поверхні: realtime * /vc leave ``` -Приклад автоматичного приєднання: +Приклад автоприєднання: ```json5 { @@ -1142,39 +1142,39 @@ Discord має дві окремі голосові поверхні: realtime * } ``` -Примітки: +Нотатки: - `voice.tts` перевизначає `messages.tts` лише для голосового відтворення. -- `voice.model` перевизначає LLM, який використовується лише для відповідей у голосових каналах Discord. Залиште його незаданим, щоб успадкувати модель маршрутизованого агента. +- `voice.model` перевизначає LLM, який використовується лише для відповідей голосового каналу Discord. Залиште його неналаштованим, щоб успадкувати модель маршрутизованого агента. - STT використовує `tools.media.audio`; `voice.model` не впливає на транскрипцію. -- Перевизначення `systemPrompt` для окремого каналу Discord застосовуються до ходів голосової транскрипції для цього голосового каналу. -- Ходи голосової транскрипції визначають статус власника з Discord `allowFrom` (або `dm.allowFrom`); мовці, які не є власниками, не можуть отримати доступ до інструментів лише для власника (наприклад, `gateway` і `cron`). -- Голос Discord є opt-in для конфігурацій лише з текстом; задайте `channels.discord.voice.enabled=true` (або залиште наявний блок `channels.discord.voice`), щоб увімкнути команди `/vc`, голосовий runtime і Gateway intent `GuildVoiceStates`. -- `channels.discord.intents.voiceStates` може явно перевизначити підписку на intent стану голосу. Залиште його незаданим, щоб intent відповідав ефективному ввімкненню голосу. +- Перевизначення `systemPrompt` Discord для окремих каналів застосовуються до ходів голосової транскрипції для цього голосового каналу. +- Ходи голосової транскрипції визначають статус власника з Discord `allowFrom` (або `dm.allowFrom`); мовці, які не є власниками, не можуть отримати доступ до інструментів лише для власника (наприклад `gateway` і `cron`). +- Голос Discord є opt-in для конфігурацій лише з текстом; установіть `channels.discord.voice.enabled=true` (або залиште наявний блок `channels.discord.voice`), щоб увімкнути команди `/vc`, голосове середовище виконання та gateway intent `GuildVoiceStates`. +- `channels.discord.intents.voiceStates` може явно перевизначити підписку на intent голосового стану. Залиште неналаштованим, щоб intent відповідав ефективному ввімкненню голосу. - `voice.daveEncryption` і `voice.decryptionFailureTolerance` передаються до параметрів приєднання `@discordjs/voice`. -- Значення за замовчуванням `@discordjs/voice` — `daveEncryption=true` і `decryptionFailureTolerance=24`, якщо їх не задано. -- `voice.connectTimeoutMs` керує початковим очікуванням Ready `@discordjs/voice` для `/vc join` і спроб автоматичного приєднання. За замовчуванням: `30000`. -- `voice.reconnectGraceMs` керує тим, як довго OpenClaw чекає, доки від’єднана голосова сесія почне повторне підключення, перш ніж знищити її. За замовчуванням: `15000`. -- OpenClaw також відстежує помилки розшифрування прийому та автоматично відновлюється, виходячи з голосового каналу й повторно приєднуючись до нього після повторюваних помилок у короткому вікні. -- Якщо після оновлення журнали прийому повторно показують `DecryptionFailed(UnencryptedWhenPassthroughDisabled)`, зберіть звіт про залежності та журнали. Вбудована лінійка `@discordjs/voice` містить upstream-виправлення padding з discord.js PR #11449, яке закрило issue discord.js #11419. +- Значення за замовчуванням `@discordjs/voice` — `daveEncryption=true` і `decryptionFailureTolerance=24`, якщо вони не налаштовані. +- `voice.connectTimeoutMs` керує початковим очікуванням Ready `@discordjs/voice` для `/vc join` і спроб автоприєднання. За замовчуванням: `30000`. +- `voice.reconnectGraceMs` керує тим, як довго OpenClaw чекає, доки від’єднана голосова сесія почне перепідключення, перш ніж знищити її. За замовчуванням: `15000`. +- OpenClaw також відстежує помилки розшифрування прийому й автоматично відновлюється, виходячи з голосового каналу та приєднуючись до нього знову після повторних помилок за короткий проміжок часу. +- Якщо журнали прийому після оновлення неодноразово показують `DecryptionFailed(UnencryptedWhenPassthroughDisabled)`, зберіть звіт про залежності та журнали. Вбудована лінія `@discordjs/voice` містить upstream-виправлення padding з PR #11449 discord.js, яке закрило issue #11419 discord.js. -Пайплайн голосового каналу: +Конвеєр голосового каналу: -- Захоплення PCM Discord перетворюється на тимчасовий WAV-файл. +- Захоплення PCM Discord перетворюється на тимчасовий файл WAV. - `tools.media.audio` обробляє STT, наприклад `openai/gpt-4o-mini-transcribe`. -- Транскрипт надсилається через вхідний потік і маршрутизацію Discord, тоді як LLM відповіді працює з політикою голосового виводу, яка приховує інструмент агента `tts` і просить повернути текст, оскільки Discord voice відповідає за фінальне відтворення TTS. -- `voice.model`, якщо задано, перевизначає лише LLM відповіді для цього ходу голосового каналу. -- `voice.tts` об’єднується поверх `messages.tts`; отримане аудіо відтворюється в каналі, до якого приєднано бота. +- Транскрипт надсилається через вхід Discord і маршрутизацію, тоді як LLM відповіді працює з політикою голосового виводу, яка приховує інструмент агента `tts` і просить повернутий текст, бо голос Discord володіє фінальним відтворенням TTS. +- `voice.model`, якщо налаштовано, перевизначає лише LLM відповіді для цього ходу голосового каналу. +- `voice.tts` об’єднується поверх `messages.tts`; отримане аудіо відтворюється в приєднаному каналі. -Облікові дані розв’язуються для кожного компонента: автентифікація маршруту LLM для `voice.model`, автентифікація STT для `tools.media.audio` і автентифікація TTS для `messages.tts`/`voice.tts`. +Облікові дані вирішуються для кожного компонента: автентифікація маршруту LLM для `voice.model`, автентифікація STT для `tools.media.audio` і автентифікація TTS для `messages.tts`/`voice.tts`. ### Голосові повідомлення -Голосові повідомлення Discord показують попередній перегляд хвильової форми та потребують аудіо OGG/Opus. OpenClaw генерує хвильову форму автоматично, але потребує `ffmpeg` і `ffprobe` на хості Gateway, щоб перевіряти й конвертувати. +Голосові повідомлення Discord показують попередній перегляд хвилі й потребують аудіо OGG/Opus. OpenClaw генерує хвилю автоматично, але потребує `ffmpeg` і `ffprobe` на хості Gateway для перевірки та перетворення. -- Надайте **локальний шлях до файлу** (URL відхиляються). -- Опустіть текстовий вміст (Discord відхиляє текст + голосове повідомлення в одному payload). -- Приймається будь-який аудіоформат; OpenClaw конвертує в OGG/Opus за потреби. +- Надайте **шлях до локального файлу** (URL відхиляються). +- Опустіть текстовий вміст (Discord відхиляє текст + голосове повідомлення в тому самому payload). +- Приймається будь-який аудіоформат; OpenClaw перетворює на OGG/Opus за потреби. ```bash message(action="send", channel="discord", target="channel:123", path="/path/to/audio.mp3", asVoice=true) @@ -1183,19 +1183,19 @@ message(action="send", channel="discord", target="channel:123", path="/path/to/a ## Усунення несправностей - + - увімкніть Message Content Intent - - увімкніть Server Members Intent, коли ви залежите від розв’язання користувача/учасника + - увімкніть Server Members Intent, коли ви залежите від вирішення користувача/учасника - перезапустіть gateway після зміни intents - + - перевірте `groupPolicy` - - перевірте allowlist guild у `channels.discord.guilds` - - якщо існує map `channels` guild, дозволені лише перелічені канали + - перевірте список дозволених guild у `channels.discord.guilds` + - якщо існує мапа guild `channels`, дозволені лише перелічені канали - перевірте поведінку `requireMention` і шаблони згадок Корисні перевірки: @@ -1208,29 +1208,29 @@ openclaw logs --follow - + Поширені причини: - - `groupPolicy="allowlist"` без відповідного allowlist guild/каналу - - `requireMention` налаштовано в неправильному місці (має бути в `channels.discord.guilds` або записі каналу) - - відправника заблоковано allowlist `users` guild/каналу + - `groupPolicy="allowlist"` без відповідного списку дозволених guild/channel + - `requireMention` налаштовано в неправильному місці (має бути під `channels.discord.guilds` або в записі каналу) + - відправника заблоковано списком дозволених `users` для guild/channel - + Типові журнали: - `Slow listener detected ...` - `stuck session: sessionKey=agent:...:discord:... state=processing ...` - Параметри черги Gateway Discord: + Регулятори черги gateway Discord: - один обліковий запис: `channels.discord.eventQueue.listenerTimeout` - кілька облікових записів: `channels.discord.accounts..eventQueue.listenerTimeout` - - це керує лише роботою слухача Gateway Discord, а не тривалістю ходу агента + - це керує лише роботою слухача gateway Discord, а не часом життя ходу агента - Discord не застосовує тайм-аут, що належить каналу, до поставлених у чергу ходів агента. Слухачі повідомлень передають роботу негайно, а поставлені в чергу запуски Discord зберігають порядок у межах сесії, доки життєвий цикл сесії/інструмента/runtime не завершиться або не перерве роботу. + Discord не застосовує timeout, що належить каналу, до поставлених у чергу ходів агента. Слухачі повідомлень передають роботу негайно, а поставлені в чергу запуски Discord зберігають порядок у межах сесії, доки життєвий цикл сесії/інструмента/середовища виконання не завершить або не перерве роботу. ```json5 { @@ -1250,26 +1250,26 @@ openclaw logs --follow - - OpenClaw отримує метадані Discord `/gateway/bot` перед підключенням. Тимчасові збої використовують стандартний URL Gateway Discord як fallback і обмежуються за частотою в журналах. + + OpenClaw отримує метадані Discord `/gateway/bot` перед підключенням. Тимчасові збої повертаються до стандартного URL gateway Discord і обмежуються за частотою в журналах. - Параметри тайм-ауту метаданих: + Регулятори timeout метаданих: - один обліковий запис: `channels.discord.gatewayInfoTimeoutMs` - кілька облікових записів: `channels.discord.accounts..gatewayInfoTimeoutMs` - - env fallback, коли config не задано: `OPENCLAW_DISCORD_GATEWAY_INFO_TIMEOUT_MS` + - резервне значення env, коли конфігурацію не налаштовано: `OPENCLAW_DISCORD_GATEWAY_INFO_TIMEOUT_MS` - за замовчуванням: `30000` (30 секунд), максимум: `120000` - + Перевірки дозволів `channels status --probe` працюють лише для числових ID каналів. - Якщо ви використовуєте ключі slug, runtime-зіставлення все одно може працювати, але probe не може повністю перевірити дозволи. + Якщо ви використовуєте slug keys, зіставлення під час виконання все ще може працювати, але probe не може повністю перевірити дозволи. - + - DM вимкнено: `channels.discord.dm.enabled=false` - політику DM вимкнено: `channels.discord.dmPolicy="disabled"` (застаріле: `channels.discord.dm.policy`) @@ -1277,30 +1277,30 @@ openclaw logs --follow - - За замовчуванням повідомлення, створені ботом, ігноруються. + + За замовчуванням повідомлення, створені ботами, ігноруються. - Якщо ви задаєте `channels.discord.allowBots=true`, використовуйте строгі правила згадок і allowlist, щоб уникнути циклічної поведінки. - Віддавайте перевагу `channels.discord.allowBots="mentions"`, щоб приймати лише повідомлення ботів, які згадують бота. + Якщо ви встановлюєте `channels.discord.allowBots=true`, використовуйте суворі правила згадок і списків дозволених, щоб уникнути циклічної поведінки. + Надавайте перевагу `channels.discord.allowBots="mentions"`, щоб приймати лише повідомлення ботів, які згадують бота. - - підтримуйте OpenClaw актуальним (`openclaw update`), щоб була наявна логіка відновлення приймання голосу Discord - - підтвердьте `channels.discord.voice.daveEncryption=true` (за замовчуванням) - - почніть із `channels.discord.voice.decryptionFailureTolerance=24` (типове значення upstream) і налаштовуйте лише за потреби + - підтримуйте OpenClaw в актуальному стані (`openclaw update`), щоб була наявна логіка відновлення приймання голосу Discord + - підтвердьте `channels.discord.voice.daveEncryption=true` (типово) + - почніть із `channels.discord.voice.decryptionFailureTolerance=24` (типове значення upstream) і коригуйте лише за потреби - стежте в журналах за: - `discord voice: DAVE decrypt failures detected` - `discord voice: repeated decrypt failures; attempting rejoin` - - якщо збої тривають після автоматичного повторного приєднання, зберіть журнали й порівняйте з історією приймання upstream DAVE у [discord.js #11419](https://github.com/discordjs/discord.js/issues/11419) і [discord.js #11449](https://github.com/discordjs/discord.js/pull/11449) + - якщо збої тривають після автоматичного повторного приєднання, зберіть журнали й порівняйте з upstream-історією приймання DAVE у [discord.js #11419](https://github.com/discordjs/discord.js/issues/11419) і [discord.js #11449](https://github.com/discordjs/discord.js/pull/11449) -## Довідник із конфігурації +## Довідник конфігурації -Основний довідник: [Довідник із конфігурації - Discord](/uk/gateway/config-channels#discord). +Основне джерело: [Довідник конфігурації - Discord](/uk/gateway/config-channels#discord). @@ -1312,17 +1312,17 @@ openclaw logs --follow - відповідь/історія: `replyToMode`, `historyLimit`, `dmHistoryLimit`, `dms.*.historyLimit` - доставка: `textChunkLimit`, `chunkMode`, `maxLinesPerMessage` - потокове передавання: `streaming` (застарілий псевдонім: `streamMode`), `streaming.preview.toolProgress`, `draftChunk`, `blockStreaming`, `blockStreamingCoalesce` -- медіа/повтор: `mediaMaxMb` (обмежує вихідні завантаження Discord, типово `100MB`), `retry` +- медіа/повторні спроби: `mediaMaxMb` (обмежує вихідні завантаження Discord, типово `100MB`), `retry` - дії: `actions.*` - присутність: `activity`, `status`, `activityType`, `activityUrl` - UI: `ui.components.accentColor` -- функції: `threadBindings`, верхнього рівня `bindings[]` (`type: "acp"`), `pluralkit`, `execApprovals`, `intents`, `agentComponents`, `heartbeat`, `responsePrefix` +- функції: `threadBindings`, `bindings[]` верхнього рівня (`type: "acp"`), `pluralkit`, `execApprovals`, `intents`, `agentComponents`, `heartbeat`, `responsePrefix` -## Безпека й експлуатація +## Безпека та експлуатація -- Ставтеся до токенів ботів як до секретів (`DISCORD_BOT_TOKEN` бажано використовувати в контрольованих середовищах). +- Розглядайте токени ботів як секрети (`DISCORD_BOT_TOKEN` бажано використовувати в керованих середовищах). - Надавайте мінімально необхідні дозволи Discord. - Якщо розгортання/стан команд застаріли, перезапустіть gateway і повторно перевірте за допомогою `openclaw channels status --probe`. @@ -1330,19 +1330,19 @@ openclaw logs --follow - Зв’яжіть користувача Discord із gateway. + Сполучіть користувача Discord із gateway. - Поведінка групового чату та списку дозволених. + Поведінка групового чату й списку дозволених. - Маршрутизуйте вхідні повідомлення до агентів. + Спрямовуйте вхідні повідомлення до агентів. Модель загроз і посилення захисту. - Зіставляйте гільдії та канали з агентами. + Зіставляйте сервери й канали з агентами. Поведінка нативних команд. diff --git a/docs/uk/channels/groups.md b/docs/uk/channels/groups.md index 1c562d436..2a237ab6c 100644 --- a/docs/uk/channels/groups.md +++ b/docs/uk/channels/groups.md @@ -2,36 +2,36 @@ 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-01T18:34:46Z" + generated_at: "2026-05-01T23:09:52Z" model: gpt-5.5 provider: openai - source_hash: 1a75fe41f3a214c9b7d59db19c1622321d43bc16340ea70a43f1547b45c79cf0 + source_hash: 5cc33dbbcf5504cae5caa003b7427d99f5c1a2d7c850dedd5d1f58a2fe44fa04 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`. -Інакше кажучи: дозволені відправники можуть запускати OpenClaw, згадуючи його. +Переклад: відправники з allowlist можуть запускати OpenClaw, згадуючи його. **Коротко** -- **Доступ до особистих повідомлень** контролюється `*.allowFrom`. -- **Доступ до груп** контролюється `*.groupPolicy` + списками дозволів (`*.groups`, `*.groupAllowFrom`). +- **Доступ до DM** контролюється через `*.allowFrom`. +- **Доступ до груп** контролюється через `*.groupPolicy` + allowlist (`*.groups`, `*.groupAllowFrom`). - **Запуск відповіді** контролюється шлюзуванням за згадкою (`requireMention`, `/activation`). @@ -47,18 +47,18 @@ otherwise -> reply ## Видимі відповіді -Для групових/канальних кімнат OpenClaw за замовчуванням використовує `messages.groupChat.visibleReplies: "message_tool"`. -Це означає, що агент усе одно обробляє хід і може оновлювати стан пам’яті/сеансу, але його звичайна фінальна відповідь не публікується назад у кімнату автоматично. Щоб говорити видимо, агент використовує `message(action=send)`. +Для групових/канальних кімнат OpenClaw типово використовує `messages.groupChat.visibleReplies: "message_tool"`. +Це означає, що агент усе одно обробляє хід і може оновлювати стан пам’яті/сесії, але його звичайна фінальна відповідь не публікується автоматично назад у кімнату. Щоб говорити видимо, агент використовує `message(action=send)`. -Якщо інструмент повідомлень недоступний за активною політикою інструментів, OpenClaw повертається -до автоматичних видимих відповідей замість тихого приглушення відповіді. +Якщо інструмент message недоступний за активною політикою інструментів, OpenClaw +повертається до автоматичних видимих відповідей замість тихого приглушення відповіді. `openclaw doctor` попереджає про цю невідповідність. -Для прямих чатів і будь-якого іншого початкового ходу використовуйте `messages.visibleReplies: "message_tool"`, щоб застосувати таку саму поведінку видимої відповіді лише через інструмент глобально. Тестові середовища також можуть вибрати це як свій стандартний варіант, якщо значення не задано; середовище Codex робить це для прямих чатів у режимі Codex. `messages.groupChat.visibleReplies` залишається конкретнішим перевизначенням для групових/канальних кімнат. +Для прямих чатів і будь-якого іншого початкового ходу використовуйте `messages.visibleReplies: "message_tool"`, щоб застосувати таку саму поведінку видимих відповідей тільки через інструмент глобально. Тестові harness також можуть вибрати це як свій типовий варіант, коли значення не задано; harness Codex робить це для прямих чатів у режимі Codex. `messages.groupChat.visibleReplies` залишається специфічнішим перевизначенням для групових/канальних кімнат. -Це замінює старий шаблон примушування моделі відповідати `NO_REPLY` для більшості ходів у режимі спостереження. У режимі лише інструментів відсутність видимої дії просто означає не викликати інструмент повідомлень. +Це замінює старий шаблон примушування моделі відповідати `NO_REPLY` для більшості ходів у режимі спостереження. У режимі тільки через інструмент відсутність видимої дії просто означає не викликати інструмент message. -Індикатори набору тексту все ще надсилаються, поки агент працює в режимі лише інструментів. Стандартний режим набору для груп підвищено з "message" до "instant" для таких ходів, бо звичайного тексту повідомлення асистента може взагалі не бути до того, як агент вирішить, чи викликати інструмент повідомлень. Явна конфігурація режиму набору все одно має пріоритет. +Індикатори набору тексту все ще надсилаються, поки агент працює в режимі тільки через інструмент. Типовий режим набору тексту для груп підвищується з "message" до "instant" для цих ходів, тому що звичайного тексту повідомлення асистента може ніколи не бути до того, як агент вирішить, чи викликати інструмент message. Явна конфігурація режиму набору тексту все ще має пріоритет. Щоб відновити застарілі автоматичні фінальні відповіді для групових/канальних кімнат: @@ -72,10 +72,10 @@ otherwise -> reply } ``` -Gateway гаряче перезавантажує конфігурацію `messages` після збереження файлу. Перезапускайте лише +Gateway гаряче перезавантажує конфігурацію `messages` після збереження файла. Перезапускайте лише коли спостереження за файлами або перезавантаження конфігурації вимкнено в розгортанні. -Щоб вимагати, аби видимий вивід проходив через інструмент повідомлень для кожного початкового чату: +Щоб вимагати, щоб видимий вивід проходив через інструмент message для кожного початкового чату: ```json5 { @@ -85,70 +85,73 @@ Gateway гаряче перезавантажує конфігурацію `mess } ``` -Нативні слеш-команди (Discord, Telegram та інші поверхні з підтримкою нативних команд) обходять `visibleReplies: "message_tool"` і завжди відповідають видимо, щоб нативний для каналу інтерфейс команд отримав очікувану відповідь. Це стосується лише перевірених нативних ходів команд; текстово введені команди `/...` і звичайні ходи чату все ще дотримуються налаштованого стандарту групи. +Нативні slash-команди (Discord, Telegram та інші поверхні з підтримкою нативних команд) обходять `visibleReplies: "message_tool"` і завжди відповідають видимо, щоб нативний для каналу командний UI отримав очікувану відповідь. Це стосується лише перевірених нативних командних ходів; набрані текстом команди `/...` і звичайні ходи чату все ще дотримуються налаштованого типового значення для груп. -## Видимість контексту та списки дозволів +## Видимість контексту та allowlist -У безпеці груп беруть участь два різні елементи керування: +У безпеці груп задіяні два різні елементи керування: -- **Авторизація запуску**: хто може запускати агента (`groupPolicy`, `groups`, `groupAllowFrom`, специфічні для каналу списки дозволів). -- **Видимість контексту**: який додатковий контекст вводиться в модель (текст відповіді, цитати, історія гілки, переслані метадані). +- **Авторизація запуску**: хто може запускати агента (`groupPolicy`, `groups`, `groupAllowFrom`, allowlist для конкретних каналів). +- **Видимість контексту**: який додатковий контекст вставляється в модель (текст відповіді, цитати, історія треду, переслані метадані). -За замовчуванням OpenClaw надає пріоритет звичайній поведінці чату й переважно зберігає контекст таким, як його отримано. Це означає, що списки дозволів передусім визначають, хто може запускати дії, а не є універсальною межею редагування для кожного процитованого чи історичного фрагмента. +Типово OpenClaw надає пріоритет звичайній поведінці чату й здебільшого зберігає контекст у тому вигляді, у якому його отримано. Це означає, що allowlist передусім визначають, хто може запускати дії, а не є універсальною межею редагування для кожного процитованого чи історичного фрагмента. - - Деякі канали вже застосовують фільтрацію за відправником для додаткового контексту в конкретних шляхах (наприклад, початкове наповнення гілки Slack, пошуки відповіді/гілки Matrix). - - Інші канали все ще передають контекст цитати/відповіді/пересилання таким, як його отримано. + - Деякі канали вже застосовують фільтрацію за відправником для додаткового контексту в окремих шляхах (наприклад, початкове наповнення треду Slack, пошуки відповідей/тредів Matrix). + - Інші канали все ще передають контекст цитати/відповіді/пересилання в отриманому вигляді. - - `contextVisibility: "all"` (стандартно) зберігає поточну поведінку "як отримано". - - `contextVisibility: "allowlist"` фільтрує додатковий контекст до дозволених відправників. + - `contextVisibility: "all"` (типово) зберігає поточну поведінку в отриманому вигляді. + - `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників з allowlist. - `contextVisibility: "allowlist_quote"` — це `allowlist` плюс один явний виняток для цитати/відповіді. - Поки цю модель посилення захисту не реалізовано узгоджено в усіх каналах, очікуйте відмінностей залежно від поверхні. + Поки цю модель посилення захисту не буде узгоджено реалізовано в усіх каналах, очікуйте відмінностей залежно від поверхні. -![Потік групового повідомлення](/images/groups-flow.svg) +![Потік групових повідомлень](/images/groups-flow.svg) Якщо ви хочете... -| Мета | Що встановити | +| Мета | Що встановити | | -------------------------------------------- | ---------------------------------------------------------- | | Дозволити всі групи, але відповідати лише на @згадки | `groups: { "*": { requireMention: true } }` | -| Вимкнути всі групові відповіді | `groupPolicy: "disabled"` | -| Лише конкретні групи | `groups: { "": { ... } }` (без ключа `"*"`) | -| Лише ви можете запускати в групах | `groupPolicy: "allowlist"`, `groupAllowFrom: ["+1555..."]` | +| Вимкнути всі групові відповіді | `groupPolicy: "disabled"` | +| Лише конкретні групи | `groups: { "": { ... } }` (без ключа `"*"`) | +| Лише ви можете запускати в групах | `groupPolicy: "allowlist"`, `groupAllowFrom: ["+1555..."]` | +| Повторно використовувати один набір довірених відправників у різних каналах | `groupAllowFrom: ["accessGroup:operators"]` | -## Ключі сеансів +Для багаторазових allowlist відправників див. [Групи доступу](/uk/channels/access-groups). -- Групові сеанси використовують ключі сеансів `agent:::group:` (кімнати/канали використовують `agent:::channel:`). -- Теми форумів Telegram додають `:topic:` до ідентифікатора групи, щоб кожна тема мала власний сеанс. -- Прямі чати використовують основний сеанс (або окремий для кожного відправника, якщо налаштовано). -- Heartbeat пропускаються для групових сеансів. +## Ключі сесій + +- Групові сесії використовують ключі сесій `agent:::group:` (кімнати/канали використовують `agent:::channel:`). +- Теми форуму Telegram додають `:topic:` до ідентифікатора групи, щоб кожна тема мала власну сесію. +- Прямі чати використовують основну сесію (або окрему для кожного відправника, якщо налаштовано). +- Heartbeat пропускаються для групових сесій. -## Шаблон: особисті прямі повідомлення + публічні групи (один агент) +## Шаблон: особисті DM + публічні групи (один агент) -Так — це добре працює, якщо ваш "особистий" трафік — це **прямі повідомлення**, а ваш "публічний" трафік — це **групи**. +Так — це добре працює, якщо ваш "особистий" трафік — це **DM**, а ваш "публічний" трафік — це **групи**. -Чому: у режимі одного агента прямі повідомлення зазвичай потрапляють в **основний** ключ сеансу (`agent:main:main`), тоді як групи завжди використовують **неосновні** ключі сеансів (`agent:main::group:`). Якщо ви вмикаєте ізоляцію з `mode: "non-main"`, ці групові сеанси виконуються в налаштованому ізольованому бекенді, тоді як ваш основний сеанс прямих повідомлень залишається на хості. Docker є стандартним бекендом, якщо ви не вибрали інший. +Чому: у режимі одного агента DM зазвичай потрапляють в **основний** ключ сесії (`agent:main:main`), тоді як групи завжди використовують **неосновні** ключі сесій (`agent:main::group:`). Якщо ви вмикаєте ізоляцію з `mode: "non-main"`, ці групові сесії запускаються в налаштованому бекенді ізоляції, тоді як ваша основна DM-сесія залишається на хості. Docker є типовим бекендом, якщо ви не виберете інший. Це дає вам один "мозок" агента (спільний робочий простір + пам’ять), але дві позиції виконання: -- **Прямі повідомлення**: повні інструменти (хост) +- **DM**: повні інструменти (хост) - **Групи**: ізоляція + обмежені інструменти -Якщо вам потрібні справді окремі робочі простори/персони ("особисте" й "публічне" ніколи не мають змішуватися), використовуйте другого агента + прив’язки. Див. [Маршрутизація кількох агентів](/uk/concepts/multi-agent). +Якщо вам потрібні справді окремі робочі простори/персони ("особисте" і "публічне" ніколи не повинні змішуватися), використовуйте другого агента + прив’язки. Див. [Маршрутизація кількох агентів](/uk/concepts/multi-agent). - + ```json5 { agents: { @@ -172,8 +175,8 @@ Gateway гаряче перезавантажує конфігурацію `mess } ``` - - Хочете "групи можуть бачити лише теку X" замість "немає доступу до хоста"? Залиште `workspaceAccess: "none"` і змонтуйте в ізоляцію лише дозволені шляхи: + + Хочете, щоб "групи могли бачити лише папку X" замість "без доступу до хоста"? Залиште `workspaceAccess: "none"` і змонтуйте в ізольоване середовище лише шляхи з allowlist: ```json5 { @@ -200,18 +203,18 @@ Gateway гаряче перезавантажує конфігурацію `mess Пов’язане: -- Ключі конфігурації та стандартні значення: [Конфігурація Gateway](/uk/gateway/config-agents#agentsdefaultssandbox) +- Ключі конфігурації та типові значення: [Конфігурація Gateway](/uk/gateway/config-agents#agentsdefaultssandbox) - Налагодження, чому інструмент заблоковано: [Ізоляція проти політики інструментів проти підвищених прав](/uk/gateway/sandbox-vs-tool-policy-vs-elevated) -- Подробиці монтувань прив’язок: [Ізоляція](/uk/gateway/sandboxing#custom-bind-mounts) +- Подробиці монтувань bind: [Ізоляція](/uk/gateway/sandboxing#custom-bind-mounts) ## Мітки відображення -- Мітки UI використовують `displayName`, коли він доступний, у форматі `:`. +- Мітки UI використовують `displayName`, коли доступно, у форматі `:`. - `#room` зарезервовано для кімнат/каналів; групові чати використовують `g-` (нижній регістр, пробіли -> `-`, зберігати `#@+._-`). ## Політика груп -Керуйте обробкою групових/кімнатних повідомлень для кожного каналу: +Керуйте тим, як обробляються групові/кімнатні повідомлення для кожного каналу: ```json5 { @@ -258,48 +261,48 @@ Gateway гаряче перезавантажує конфігурацію `mess } ``` -| Політика | Поведінка | +| Політика | Поведінка | | ------------- | ------------------------------------------------------------ | -| `"open"` | Групи обходять списки дозволів; шлюзування за згадкою все ще застосовується. | -| `"disabled"` | Повністю блокувати всі групові повідомлення. | -| `"allowlist"` | Дозволяти лише групи/кімнати, що відповідають налаштованому списку дозволів. | +| `"open"` | Групи обходять allowlist; шлюзування за згадкою все ще застосовується. | +| `"disabled"` | Повністю блокувати всі групові повідомлення. | +| `"allowlist"` | Дозволяти лише групи/кімнати, які відповідають налаштованому allowlist. | - - - `groupPolicy` відокремлена від шлюзування за згадкою (яке вимагає @згадок). + + - `groupPolicy` відокремлена від шлюзування за згадкою (яке потребує @згадок). - WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo: використовуйте `groupAllowFrom` (резервний варіант: явний `allowFrom`). - - Signal: `groupAllowFrom` може збігатися або з вхідним ідентифікатором групи Signal, або з телефоном/UUID відправника. - - Схвалення парування прямих повідомлень (записи сховища `*-allowFrom`) застосовуються лише до доступу прямих повідомлень; авторизація відправника в групі залишається явно прив’язаною до групових списків дозволів. - - Discord: список дозволів використовує `channels.discord.guilds..channels`. - - Slack: список дозволів використовує `channels.slack.channels`. - - Matrix: список дозволів використовує `channels.matrix.groups`. Надавайте перевагу ідентифікаторам кімнат або псевдонімам; пошук назви приєднаної кімнати виконується за найкращою спробою, а нерозв’язані назви ігноруються під час виконання. Використовуйте `channels.matrix.groupAllowFrom`, щоб обмежити відправників; також підтримуються списки дозволів `users` для кожної кімнати. - - Групові прямі повідомлення контролюються окремо (`channels.discord.dm.*`, `channels.slack.dm.*`). - - Список дозволів Telegram може збігатися з ідентифікаторами користувачів (`"123456789"`, `"telegram:123456789"`, `"tg:123456789"`) або іменами користувачів (`"@alice"` чи `"alice"`); префікси нечутливі до регістру. - - Стандартне значення — `groupPolicy: "allowlist"`; якщо ваш груповий список дозволів порожній, групові повідомлення блокуються. + - Signal: `groupAllowFrom` може відповідати або вхідному ідентифікатору групи Signal, або телефону/UUID відправника. + - Схвалення сполучення DM (записи сховища `*-allowFrom`) застосовуються лише до доступу DM; авторизація відправника в групі лишається явно прив’язаною до групових allowlist. + - Discord: allowlist використовує `channels.discord.guilds..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.` відсутній), політика груп повертається до режиму fail-closed (зазвичай `allowlist`) замість успадкування `channels.defaults.groupPolicy`. -Швидка ментальна модель (порядок оцінювання групових повідомлень): +Швидка ментальна модель (порядок оцінювання для групових повідомлень): - `groupPolicy` (відкрита/вимкнена/список дозволених). + `groupPolicy` (open/disabled/allowlist). Списки дозволених груп (`*.groups`, `*.groupAllowFrom`, список дозволених для конкретного каналу). - - Обмеження за згадкою (`requireMention`, `/activation`). + + Фільтрація за згадкою (`requireMention`, `/activation`). -## Обмеження за згадкою (типово) +## Фільтрація за згадкою (типово) -Повідомлення в групах потребують згадки, якщо це не перевизначено для окремої групи. Типові значення задаються для кожної підсистеми в `*.groups."*"`. +Групові повідомлення потребують згадки, якщо це не перевизначено для групи. Типові значення зберігаються для кожної підсистеми в `*.groups."*"`. -Відповідь на повідомлення бота рахується як неявна згадка, коли канал підтримує метадані відповіді. Цитування повідомлення бота також може рахуватися як неявна згадка в каналах, які надають метадані цитування. Поточні вбудовані випадки включають Telegram, WhatsApp, Slack, Discord, Microsoft Teams і ZaloUser. +Відповідь на повідомлення бота вважається неявною згадкою, коли канал підтримує метадані відповіді. Цитування повідомлення бота також може вважатися неявною згадкою в каналах, які надають метадані цитування. Поточні вбудовані випадки включають Telegram, WhatsApp, Slack, Discord, Microsoft Teams і ZaloUser. ```json5 { @@ -338,38 +341,38 @@ Gateway гаряче перезавантажує конфігурацію `mess ``` - - - `mentionPatterns` — це безпечні regex-шаблони без урахування регістру; недійсні шаблони та небезпечні форми вкладеного повторення ігноруються. - - Поверхні, які надають явні згадки, усе одно проходять; шаблони є запасним варіантом. + + - `mentionPatterns` — це безпечні regex-шаблони без урахування регістру; недійсні шаблони й небезпечні форми з вкладеним повторенням ігноруються. + - Поверхні, які надають явні згадки, усе одно проходять; шаблони є резервним варіантом. - Перевизначення для окремого агента: `agents.list[].groupChat.mentionPatterns` (корисно, коли кілька агентів спільно використовують групу). - - Обмеження за згадкою застосовується лише тоді, коли виявлення згадки можливе (налаштовано нативні згадки або `mentionPatterns`). - - Додавання групи або відправника до списку дозволених не вимикає обмеження за згадкою; установіть для цієї групи `requireMention` значення `false`, коли всі повідомлення мають запускати обробку. - - Контекст промпта групового чату переносить визначену інструкцію тихої відповіді на кожному ході; файли робочого простору не повинні дублювати механіку `NO_REPLY`. - - Групи, де дозволені тихі відповіді, трактують чисті порожні або лише reasoning-відповіді моделі як тихі, еквівалентні `NO_REPLY`. Прямі чати роблять те саме лише тоді, коли прямі тихі відповіді явно дозволені; інакше порожні відповіді залишаються невдалими ходами агента. - - Типові значення Discord містяться в `channels.discord.guilds."*"` (можна перевизначати для окремої гільдії/каналу). - - Контекст історії груп загортається однаково для всіх каналів і є **лише відкладеним** (повідомлення, пропущені через обмеження за згадкою); використовуйте `messages.groupChat.historyLimit` для глобального типового значення та `channels..historyLimit` (або `channels..accounts.*.historyLimit`) для перевизначень. Установіть `0`, щоб вимкнути. + - Фільтрація за згадкою застосовується лише тоді, коли виявлення згадок можливе (налаштовано нативні згадки або `mentionPatterns`). + - Додавання групи чи відправника до списку дозволених не вимикає фільтрацію за згадкою; встановіть для цієї групи `requireMention` у `false`, коли всі повідомлення мають запускати відповідь. + - Контекст підказки групового чату передає визначену інструкцію тихої відповіді на кожному ході; файли робочого простору не повинні дублювати механіку `NO_REPLY`. + - Групи, де дозволені тихі відповіді, трактують чисті порожні або лише міркувальні ходи моделі як тишу, еквівалентну `NO_REPLY`. Прямі чати роблять те саме лише тоді, коли прямі тихі відповіді явно дозволені; інакше порожні відповіді залишаються невдалими ходами агента. + - Типові значення Discord зберігаються в `channels.discord.guilds."*"` (можна перевизначити для окремої гільдії/каналу). + - Контекст історії групи однаково обгортається в усіх каналах і є **лише відкладеним** (повідомлення, пропущені через фільтрацію за згадкою); використовуйте `messages.groupChat.historyLimit` для глобального типового значення та `channels..historyLimit` (або `channels..accounts.*.historyLimit`) для перевизначень. Встановіть `0`, щоб вимкнути. -## Обмеження інструментів для групи/каналу (необов’язково) +## Обмеження інструментів групи/каналу (необов’язково) -Деякі конфігурації каналів підтримують обмеження того, які інструменти доступні **всередині конкретної групи/кімнати/каналу**. +Деякі конфігурації каналів підтримують обмеження, які інструменти доступні **всередині конкретної групи/кімнати/каналу**. - `tools`: дозволити/заборонити інструменти для всієї групи. - `toolsBySender`: перевизначення для окремих відправників у межах групи. Використовуйте явні префікси ключів: `id:`, `e164:`, `username:`, `name:` і wildcard `"*"`. Застарілі ключі без префікса все ще приймаються й зіставляються лише як `id:`. -Порядок розв’язання (найконкретніший перемагає): +Порядок розв’язання (найконкретніше перемагає): Збіг `toolsBySender` для групи/каналу. - `tools` для групи/каналу. + `tools` групи/каналу. - Типовий (`"*"`) збіг `toolsBySender`. + Збіг типового (`"*"`) `toolsBySender`. Типові (`"*"`) `tools`. @@ -397,21 +400,21 @@ Gateway гаряче перезавантажує конфігурацію `mess ``` -Обмеження інструментів для групи/каналу застосовуються на додачу до глобальної політики інструментів або політики інструментів агента (заборона все одно перемагає). Деякі канали використовують іншу вкладеність для кімнат/каналів (наприклад, Discord `guilds.*.channels.*`, Slack `channels.*`, Microsoft Teams `teams.*.channels.*`). +Обмеження інструментів групи/каналу застосовуються на додачу до глобальної політики інструментів або політики інструментів агента (заборона все одно перемагає). Деякі канали використовують іншу вкладеність для кімнат/каналів (наприклад, Discord `guilds.*.channels.*`, Slack `channels.*`, Microsoft Teams `teams.*.channels.*`). ## Списки дозволених груп -Коли налаштовано `channels.whatsapp.groups`, `channels.telegram.groups` або `channels.imessage.groups`, ключі діють як список дозволених груп. Використовуйте `"*"`, щоб дозволити всі групи, одночасно задавши типову поведінку згадки. +Коли налаштовано `channels.whatsapp.groups`, `channels.telegram.groups` або `channels.imessage.groups`, ключі діють як список дозволених груп. Використовуйте `"*"`, щоб дозволити всі групи, водночас задаючи типову поведінку щодо згадок. -Поширена плутанина: схвалення сполучення DM — це не те саме, що авторизація групи. Для каналів, які підтримують сполучення DM, сховище сполучень розблоковує лише DM. Групові команди все ще потребують явної авторизації відправника групи зі списків дозволених у конфігурації, таких як `groupAllowFrom`, або задокументованого резервного варіанта конфігурації для цього каналу. +Поширена плутанина: схвалення створення пари для DM — це не те саме, що авторизація групи. Для каналів, які підтримують створення пари для DM, сховище пар розблоковує лише DM. Групові команди все ще потребують явної авторизації відправника групи зі списків дозволених у конфігурації, як-от `groupAllowFrom`, або задокументованого резервного варіанта конфігурації для цього каналу. Поширені наміри (скопіюйте/вставте): - + ```json5 { channels: { whatsapp: { groupPolicy: "disabled" } }, @@ -443,7 +446,7 @@ Gateway гаряче перезавантажує конфігурацію `mess } ``` - + ```json5 { channels: { @@ -465,41 +468,41 @@ 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 з локальної бази даних Контактів перед заповненням `GroupMembers`. Це вимкнено за замовчуванням і запускається лише після проходження звичайного обмеження групи. +- BlueBubbles може необов’язково доповнювати безіменних учасників груп macOS з локальної бази даних Contacts перед заповненням `GroupMembers`. Це вимкнено за замовчуванням і запускається лише після проходження звичайної групової фільтрації. -Системний промпт агента включає вступ для групи на першому ході нової групової сесії. Він нагадує моделі відповідати як людина, уникати таблиць Markdown, мінімізувати порожні рядки й дотримуватися звичайних інтервалів у чаті, а також не вводити буквальні послідовності `\n`. Назви груп і мітки учасників, отримані з каналів, відображаються як відмежовані ненадійні метадані, а не як вбудовані системні інструкції. +Системна підказка агента містить груповий вступ на першому ході нової групової сесії. Вона нагадує моделі відповідати як людина, уникати Markdown-таблиць, мінімізувати порожні рядки й дотримуватися звичайних інтервалів у чаті, а також не вводити буквальні послідовності `\n`. Назви груп і мітки учасників, отримані з каналу, відображаються як огороджені недовірені метадані, а не як вбудовані системні інструкції. -## Специфіка iMessage +## Особливості iMessage - Надавайте перевагу `chat_id:` під час маршрутизації або додавання до списку дозволених. - Список чатів: `imsg chats --limit 20`. -- Відповіді в групах завжди повертаються до того самого `chat_id`. +- Групові відповіді завжди повертаються до того самого `chat_id`. -## Системні промпти WhatsApp +## Системні підказки 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/group-messages) +- [Створення пари](/uk/channels/pairing) diff --git a/docs/uk/channels/pairing.md b/docs/uk/channels/pairing.md index 0b0fbd8d5..c82423355 100644 --- a/docs/uk/channels/pairing.md +++ b/docs/uk/channels/pairing.md @@ -1,62 +1,66 @@ --- read_when: - Налаштування контролю доступу до особистих повідомлень - - Створення пари з новим iOS/Android Node + - Сполучення нового iOS/Android Node - Огляд стану безпеки OpenClaw -summary: 'Огляд сполучення: схвалюйте, хто може писати вам у приватні повідомлення + які вузли можуть приєднуватися' +summary: 'Огляд сполучення: схвалюйте, хто може надсилати вам особисті повідомлення + які вузли можуть приєднуватися' title: Сполучення x-i18n: - generated_at: "2026-05-01T22:59:51Z" + generated_at: "2026-05-01T23:10:05Z" model: gpt-5.5 provider: openai - source_hash: b11f4b538b9100e14c3dfe13c7a64995e5cebfc1c459839c6fa7a397f4cfb9ec + source_hash: bb68d87c0e1dfe7c9a6a6d9415f4c63625755fb43a2e22a1d1374ff0a63e49c4 source_path: channels/pairing.md workflow: 16 --- -«Сполучення» — це явний етап схвалення доступу в OpenClaw. +«Сполучення» — це явний крок затвердження доступу в OpenClaw. Воно використовується у двох місцях: -1. **Сполучення DM** (кому дозволено спілкуватися з ботом) +1. **Сполучення DM** (кому дозволено говорити з ботом) 2. **Сполучення Node** (яким пристроям/вузлам дозволено приєднуватися до мережі Gateway) Контекст безпеки: [Безпека](/uk/gateway/security) -## 1) Сполучення DM (доступ до вхідного чату) +## 1) Сполучення DM (вхідний доступ до чату) -Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви не схвалите доступ. +Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви його не затвердите. -Стандартні політики DM задокументовано тут: [Безпека](/uk/gateway/security) +Типові політики DM задокументовано тут: [Безпека](/uk/gateway/security) -`dmPolicy: "open"` є публічною лише тоді, коли ефективний список дозволених DM містить `"*"`. -Налаштування й перевірка потребують цього wildcard для публічно відкритих конфігурацій. Якщо наявний -стан містить `open` із конкретними записами `allowFrom`, під час виконання все одно допускаються -лише ці відправники, а схвалення зі сховища сполучення не розширюють доступ `open`. +`dmPolicy: "open"` є публічним лише тоді, коли ефективний список дозволених DM містить `"*"`. +Налаштування й перевірка вимагають цей wildcard для публічно відкритих конфігурацій. Якщо наявний +стан містить `open` з конкретними записами `allowFrom`, runtime усе одно допускає +лише цих відправників, а затвердження у сховищі сполучень не розширюють доступ `open`. Коди сполучення: - 8 символів, великі літери, без неоднозначних символів (`0O1I`). - **Спливають через 1 годину**. Бот надсилає повідомлення про сполучення лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника). -- Очікувані запити сполучення DM за замовчуванням обмежено **3 на канал**; додаткові запити ігноруються, доки один із них не спливе або не буде схвалений. +- Очікувані запити сполучення DM типово обмежено **3 на канал**; додаткові запити ігноруються, доки один не спливе або не буде затверджений. -### Схвалити відправника +### Затвердити відправника ```bash openclaw pairing list telegram openclaw pairing approve telegram ``` -Якщо власника команд ще не налаштовано, схвалення коду сполучення DM також початково -заповнює `commands.ownerAllowFrom` схваленим відправником, наприклад `telegram:123456789`. -Це дає першому налаштуванню явного власника для привілейованих команд і запитів -схвалення виконання. Після появи власника подальші схвалення сполучення надають лише -доступ DM; вони не додають більше власників. +Якщо власника команд ще не налаштовано, затвердження коду сполучення DM також початково налаштовує +`commands.ownerAllowFrom` на затвердженого відправника, наприклад `telegram:123456789`. +Це дає першим налаштуванням явного власника для привілейованих команд і запитів +затвердження exec. Після появи власника подальші затвердження сполучення надають лише доступ +DM; вони не додають більше власників. Підтримувані канали: `bluebubbles`, `discord`, `feishu`, `googlechat`, `imessage`, `irc`, `line`, `matrix`, `mattermost`, `msteams`, `nextcloud-talk`, `nostr`, `openclaw-weixin`, `signal`, `slack`, `synology-chat`, `telegram`, `twitch`, `whatsapp`, `zalo`, `zalouser`. ### Багаторазові групи відправників -Використовуйте верхньорівневі `accessGroups`, коли той самий набір довірених відправників має застосовуватися до кількох каналів повідомлень або до списків дозволених як для DM, так і для груп. Статичні групи відправників використовують `type: "message.senders"` і перелічують учасників у звичайному для кожного каналу синтаксисі `allowFrom`. +Використовуйте верхньорівневі `accessGroups`, коли той самий набір довірених відправників має застосовуватися до +кількох каналів повідомлень або і до списків дозволених DM, і до групових списків дозволених. + +Статичні групи використовують `type: "message.senders"` і посилаються через +`accessGroup:` зі списків дозволених каналу: ```json5 { @@ -64,7 +68,6 @@ openclaw pairing approve telegram operators: { type: "message.senders", members: { - "*": ["global-owner-id"], discord: ["discord:123456789012345678"], telegram: ["987654321"], whatsapp: ["+15551234567"], @@ -78,67 +81,67 @@ openclaw pairing approve telegram } ``` -Список учасників `"*"` спільний для всіх каналів повідомлень. Списки, специфічні для каналу, перевіряються за власними правилами зіставлення відправників цього каналу. +Групи доступу докладно задокументовано тут: [Групи доступу](/uk/channels/access-groups) ### Де зберігається стан Зберігається в `~/.openclaw/credentials/`: - Очікувані запити: `-pairing.json` -- Сховище схваленого списку дозволених: - - Обліковий запис за замовчуванням: `-allowFrom.json` - - Обліковий запис не за замовчуванням: `--allowFrom.json` +- Сховище затвердженого списку дозволених: + - Типовий обліковий запис: `-allowFrom.json` + - Нетиповий обліковий запис: `--allowFrom.json` -Поведінка областей дії облікових записів: +Поведінка області дії облікового запису: -- Облікові записи не за замовчуванням читають/записують лише свій файл списку дозволених з областю дії. -- Обліковий запис за замовчуванням використовує файл списку дозволених каналу без області дії. +- Нетипові облікові записи читають/записують лише свій файл списку дозволених з областю дії. +- Типовий обліковий запис використовує каналовий файл списку дозволених без області дії. -Ставтеся до них як до чутливих даних (вони керують доступом до вашого асистента). +Ставтеся до них як до конфіденційних (вони керують доступом до вашого асистента). -Сховище списку дозволених для сполучення призначене для доступу DM. Авторизація груп є окремою. -Схвалення коду сполучення DM не дозволяє цьому відправнику автоматично виконувати групові -команди або керувати ботом у групах. Початкове встановлення першого власника — це окремий стан -конфігурації в `commands.ownerAllowFrom`, а доставка групового чату все одно дотримується -групових списків дозволених каналу (наприклад `groupAllowFrom`, `groups` або перевизначень -для окремої групи чи теми залежно від каналу). +Сховище списку дозволених сполучення призначене для доступу DM. Авторизація груп є окремою. +Затвердження коду сполучення DM автоматично не дозволяє цьому відправнику виконувати групові +команди або керувати ботом у групах. Початкове налаштування першого власника є окремим станом конфігурації +в `commands.ownerAllowFrom`, а доставка групового чату й далі дотримується +групових списків дозволених каналу (наприклад `groupAllowFrom`, `groups` або перевизначень для окремих груп +чи тем залежно від каналу). -## 2) Сполучення пристроїв Node (iOS/Android/macOS/headless Node) +## 2) Сполучення пристрою Node (вузли iOS/Android/macOS/headless) -Node підключаються до Gateway як **пристрої** з `role: node`. Gateway -створює запит на сполучення пристрою, який потрібно схвалити. +Вузли підключаються до Gateway як **пристрої** з `role: node`. Gateway +створює запит на сполучення пристрою, який потрібно затвердити. ### Сполучення через Telegram (рекомендовано для iOS) -Якщо ви використовуєте Plugin `device-pair`, перше сполучення пристрою можна повністю виконати з Telegram: +Якщо ви використовуєте Plugin `device-pair`, перше сполучення пристрою можна виконати повністю з Telegram: 1. У Telegram напишіть своєму боту: `/pair` -2. Бот відповість двома повідомленнями: повідомленням з інструкцією та окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram). +2. Бот відповідає двома повідомленнями: повідомленням з інструкціями та окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram). 3. На телефоні відкрийте застосунок OpenClaw для iOS → Settings → Gateway. 4. Вставте код налаштування й підключіться. -5. Поверніться в Telegram: `/pair pending` (перегляньте ID запитів, роль і області дії), потім схваліть. +5. Назад у Telegram: `/pair pending` (перегляньте ID запитів, роль і області дії), потім затвердьте. -Код налаштування — це JSON-навантаження, закодоване в base64, яке містить: +Код налаштування — це JSON-пейлоад, закодований у base64, який містить: -- `url`: URL WebSocket для Gateway (`ws://...` або `wss://...`) -- `bootstrapToken`: короткочасний bootstrap-токен для одного пристрою, що використовується для початкового рукостискання сполучення +- `url`: URL WebSocket Gateway (`ws://...` або `wss://...`) +- `bootstrapToken`: короткоживучий bootstrap-токен для одного пристрою, який використовується для початкового рукостискання сполучення -Цей bootstrap-токен несе вбудований bootstrap-профіль сполучення: +Цей bootstrap-токен має вбудований bootstrap-профіль сполучення: -- основний переданий токен `node` залишається з `scopes: []` -- будь-який переданий токен `operator` залишається обмеженим bootstrap-списком дозволених: +- основний переданий токен `node` лишається `scopes: []` +- будь-який переданий токен `operator` лишається обмеженим bootstrap-списком дозволених: `operator.approvals`, `operator.read`, `operator.talk.secrets`, `operator.write` -- перевірки bootstrap-областей дії мають префікс ролі, а не один плаский пул областей дії: +- перевірки bootstrap-областей дії мають префікс ролі, а не один плоский пул областей дії: записи областей дії operator задовольняють лише запити operator, а ролі не-operator - все одно мають запитувати області дії з власним префіксом ролі -- подальша ротація/відкликання токенів залишається обмеженою як схваленим - контрактом ролі пристрою, так і областями дії operator сесії викликача + усе одно мають запитувати області дії під власним префіксом ролі +- подальша ротація/відкликання токенів лишається обмеженою і затвердженим + контрактом ролі пристрою, і областями дії operator сесії виклику -Ставтеся до коду налаштування як до пароля, доки він чинний. +Ставтеся до коду налаштування як до пароля, поки він чинний. -### Схвалити пристрій Node +### Затвердити пристрій Node ```bash openclaw devices list @@ -146,18 +149,18 @@ openclaw devices approve openclaw devices reject ``` -Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншими -роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється, і створюється новий +Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншою +роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється і створюється новий `requestId`. -Уже сполучений пристрій не отримує ширший доступ непомітно. Якщо він повторно підключається, запитуючи більше областей дії або ширшу роль, OpenClaw залишає наявне схвалення без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте `openclaw devices list`, щоб порівняти поточний схвалений доступ із новим запитаним доступом перед схваленням. +Уже сполучений пристрій не отримує ширший доступ непомітно. Якщо він перепідключається й просить більше областей дії або ширшу роль, OpenClaw лишає наявне затвердження без змін і створює новий очікуваний запит на підвищення. Використовуйте `openclaw devices list`, щоб порівняти поточний затверджений доступ із новим запитаним доступом перед затвердженням. -### Необов’язкове автоматичне схвалення Node для довірених CIDR +### Необов’язкове автоматичне затвердження Node за довіреним CIDR -Сполучення пристроїв за замовчуванням залишається ручним. Для суворо контрольованих мереж Node -можна ввімкнути автоматичне схвалення першого Node з явними CIDR або точними IP-адресами: +Сполучення пристроїв типово лишається ручним. Для суворо контрольованих мереж Node +можна увімкнути автоматичне затвердження першого Node з явними CIDR або точними IP: ```json5 { @@ -172,28 +175,28 @@ openclaw devices reject ``` Це застосовується лише до нових запитів сполучення `role: node` без запитаних -областей дії. Клієнти operator, browser, Control UI та WebChat усе ще потребують ручного -схвалення. Зміни ролі, області дії, метаданих і публічного ключа також потребують ручного -схвалення. +областей дії. Клієнти operator, browser, Control UI і WebChat усе одно потребують ручного +затвердження. Зміни ролі, області дії, метаданих і публічного ключа також потребують ручного +затвердження. ### Зберігання стану сполучення Node Зберігається в `~/.openclaw/devices/`: -- `pending.json` (короткочасний; очікувані запити спливають) +- `pending.json` (короткоживучий; очікувані запити спливають) - `paired.json` (сполучені пристрої + токени) ### Примітки - Застарілий API `node.pair.*` (CLI: `openclaw nodes pending|approve|reject|remove|rename`) є - окремим сховищем сполучення, яким володіє Gateway. WS Node все ще потребують сполучення пристроїв. -- Запис сполучення є довготривалим джерелом істини для схвалених ролей. Активні - токени пристроїв залишаються обмеженими цим схваленим набором ролей; випадковий запис токена - поза схваленими ролями не створює нового доступу. + окремим сховищем сполучення, яким володіє gateway. WS-вузли все одно потребують сполучення пристрою. +- Запис сполучення є тривалим джерелом істини для затверджених ролей. Активні + токени пристрою лишаються обмеженими цим затвердженим набором ролей; випадковий запис токена + поза затвердженими ролями не створює нового доступу. ## Пов’язані документи -- Модель безпеки + ін’єкція в prompt: [Безпека](/uk/gateway/security) +- Модель безпеки + prompt injection: [Безпека](/uk/gateway/security) - Безпечне оновлення (запустіть doctor): [Оновлення](/uk/install/updating) - Конфігурації каналів: - Telegram: [Telegram](/uk/channels/telegram) diff --git a/docs/uk/ci.md b/docs/uk/ci.md index a6d857b99..feedf5e20 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,75 +1,75 @@ --- read_when: - - Потрібно зрозуміти, чому завдання CI запустилося або не запустилося + - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося - Ви налагоджуєте перевірку GitHub Actions, яка не проходить - - Ви координуєте запуск або повторний запуск перевірки релізу -summary: Граф завдань CI, перевірки за обсягом, релізні парасолькові перевірки та локальні еквіваленти команд -title: Конвеєр CI + - Ви координуєте запуск або повторний запуск валідації релізу +summary: Граф завдань CI, шлюзи області дії, релізні парасолі та локальні еквіваленти команд +title: CI-конвеєр x-i18n: - generated_at: "2026-05-01T22:37:32Z" + generated_at: "2026-05-01T23:10:06Z" model: gpt-5.5 provider: openai - source_hash: c6d284871bfc5f8c4740bd729563070baf396c60a2769f49c521c44dd709addf + source_hash: 4475dd906e2a7b7675a01ec72e7782f75ccbb4769bd0333c3f56acea9f343893 source_path: ci.md workflow: 16 --- -OpenClaw CI запускається під час кожного push до `main` і для кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі напрямки, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне звуження області та розгортають увесь граф для кандидатів на реліз і широкої перевірки. Напрямки Android залишаються opt-in через `include_android`. Покриття Plugin лише для релізів міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або через явний ручний dispatch. +OpenClaw CI запускається для кожного push у `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі лінії, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області й розгортають повний граф для реліз-кандидатів і широкої валідації. Android-лінії залишаються opt-in через `include_android`. Покриття Plugin лише для релізу міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або через явний ручний dispatch. -## Огляд pipeline +## Огляд конвеєра | Завдання | Призначення | Коли запускається | | -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє зміни лише в docs, змінені області, змінені extensions і створює CI manifest | Завжди для не-draft push і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для не-draft push і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей за npm advisories | Завжди для не-draft push і PR | -| `security-fast` | Обов’язковий aggregate для швидких security-завдань | Завжди для не-draft push і PR | -| `check-dependencies` | Production Knip dependency-only pass плюс guard allowlist для невикористаних файлів | Зміни, релевантні для Node | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built-artifact і reusable downstream artifacts | Зміни, релевантні для Node | -| `checks-fast-core` | Швидкі Linux-напрямки коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні для Node | -| `checks-fast-contracts-channels` | Sharded перевірки контрактів каналів зі стабільним aggregate check result | Зміни, релевантні для Node | -| `checks-node-core-test` | Шарди Core Node test, крім напрямків channel, bundled, contract і extension | Зміни, релевантні для Node | -| `check` | Sharded еквівалент головного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | -| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Зміни, релевантні для Node | -| `build-smoke` | Built-CLI smoke-тести і startup-memory smoke | Зміни, релевантні для Node | -| `checks` | Verifier для built-artifact channel tests | Зміни, релевантні для Node | -| `checks-node-compat-node22` | Збірка сумісності з Node 22 і smoke-напрямок | Ручний CI dispatch для релізів | -| `check-docs` | Форматування docs, lint і перевірки broken-link | Docs змінено | -| `skills-python` | Ruff + pytest для Skills на Python | Зміни, релевантні для Python-skill | -| `checks-windows` | Специфічні для Windows тести process/path плюс спільні регресії runtime import specifier | Зміни, релевантні для Windows | -| `macos-node` | macOS TypeScript test lane зі спільними built artifacts | Зміни, релевантні для macOS | -| `macos-swift` | Swift lint, build і tests для застосунку macOS | Зміни, релевантні для macOS | -| `android` | Android unit tests для обох flavors плюс одна debug APK build | Зміни, релевантні для Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після trusted activity | Успіх main CI або ручний dispatch | +| `preflight` | Виявляє зміни лише в документації, змінені області, змінені розширення та будує CI-маніфест | Завжди для нечернеткових push і PR | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для нечернеткових push і PR | +| `security-dependency-audit` | Аудит production lockfile без встановлення залежностей щодо npm advisories | Завжди для нечернеткових push і PR | +| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для нечернеткових push і PR | +| `check-dependencies` | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів | Зміни, релевантні для Node | +| `build-artifacts` | Збірка `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані артефакти для downstream | Зміни, релевантні для Node | +| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні для Node | +| `checks-fast-contracts-channels` | Sharded-перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | +| `checks-node-core-test` | Шарди тестів Core Node, крім ліній каналів, bundled, contract і extension | Зміни, релевантні для Node | +| `check` | Sharded-еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | +| `check-additional` | Шарди architecture, boundary, extension-surface guards, package-boundary і gateway-watch | Зміни, релевантні для Node | +| `build-smoke` | Smoke-тести зібраного CLI і startup-memory smoke | Зміни, релевантні для Node | +| `checks` | Верифікатор для тестів каналів зібраних артефактів | Зміни, релевантні для Node | +| `checks-node-compat-node22` | Лінія збірки та smoke для сумісності з Node 22 | Ручний CI dispatch для релізів | +| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено | +| `skills-python` | Ruff + pytest для Python-backed skills | Зміни, релевантні для Python skills | +| `checks-windows` | Специфічні для Windows тести процесів/шляхів плюс регресії shared runtime import specifier | Зміни, релевантні для Windows | +| `macos-node` | Лінія TypeScript-тестів macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | +| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні для macOS | +| `android` | Unit-тести Android для обох flavors плюс одна збірка debug APK | Зміни, релевантні для Android | +| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх Main CI або ручний dispatch | -## Порядок fail-fast +## Порядок швидкого завершення при помилці -1. `preflight` вирішує, які напрямки взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи на важчі artifact і platform matrix jobs. -3. `build-artifacts` перекривається зі швидкими Linux-напрямками, щоб downstream consumers могли стартувати щойно спільна збірка готова. -4. Важчі platform і runtime напрямки розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` вирішує, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих завдань матриці артефактів і платформ. +3. `build-artifacts` перекривається зі швидкими Linux-лініями, щоб downstream-споживачі могли стартувати, щойно спільна збірка буде готова. +4. Важчі платформні й runtime-лінії розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все ще повідомляють про звичайні shard failures, але не стають у чергу після того, як увесь workflow уже було замінено. Автоматичний CI concurrency key версіонований (`CI-v7-*`), щоб zombie на боці GitHub у старій queue group не міг безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. +GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший запуск для того самого ref також не падає. Агреговані перевірки шардів використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні помилки шардів, але не стають у чергу після того, як увесь workflow уже було замінено. Автоматичний ключ concurrency CI версійований (`CI-v7-*`), тож zombie з боку GitHub у старій групі черги не може безстроково блокувати новіші запуски main. Ручні запуски повного suite використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються. ## Область і маршрутизація -Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби змінилася кожна scoped area. +Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає виявлення changed-scope і змушує preflight-маніфест поводитися так, ніби змінилася кожна scoped-ділянка. -- **Зміни CI workflow** перевіряють граф Node CI плюс workflow linting, але самі по собі не примушують запускати Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source. -- **Зміни лише маршрутизації CI, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму. -- **Windows Node checks** scoped до специфічних для Windows process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цей lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes. +- **Редагування CI workflow** валідують граф Node CI плюс workflow linting, але самі по собі не змушують виконувати native-збірки Windows, Android або macOS; ці платформні лінії залишаються обмеженими змінами платформного source. +- **Редагування лише CI routing, вибрані дешеві редагування core-test fixture і вузькі редагування plugin contract helper/test-routing** використовують швидкий шлях маніфесту лише для Node: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність із Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові матриці guard, коли зміна обмежена routing або helper-поверхнями, які швидке завдання безпосередньо перевіряє. +- **Windows Node checks** обмежені специфічними для Windows process/path wrappers, npm/pnpm/UI runner helpers, конфігурацією package manager і CI workflow-поверхнями, що виконують цю лінію; непов’язані зміни source, plugin, install-smoke і лише тестові зміни залишаються на Linux Node-лініях. -Найповільніші сімейства Node test розділено або збалансовано, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes об’єднано в пари, auto-reply запускається як чотири збалансовані workers (з reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/plugin configs розподілено між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries з використанням CI shard name, щоб `.artifacts/vitest-shard-timings.json` міг відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards паралельно в одному job. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано. +Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runners: channel contracts виконуються як три зважені шарди, малі core unit-лінії спарені, auto-reply виконується як чотири збалансовані workers (із розділенням reply subtree на шарди agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування build artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із використанням імені CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards паралельно всередині одного job. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor із SMS/call-log BuildConfig flags, водночас уникаючи duplicate debug APK packaging job під час кожного Android-relevant push. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor з BuildConfig flags для SMS/call-log, водночас уникаючи дубльованого debug APK packaging job для кожного Android-relevant push. -Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до найновішої версії Knip, з вимкненим pnpm minimum release age для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або залишає stale allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати. +Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на найновішій версії Knip, із вимкненим мінімальним віком релізу pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис allowlist, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати. ## Ручні dispatch -Manual CI dispatches запускають той самий job graph, що й звичайний CI, але примусово вмикають кожен non-Android scoped lane: Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Standalone manual CI dispatches запускають Android лише з `include_android=true`; full release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, full extension batch sweep і plugin prerelease Docker lanes виключені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` dispatches окремий workflow `Plugin Prerelease` з увімкненим release-validation gate. +Ручні CI dispatch запускають той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped-лінію, крім Android: Linux Node shards, bundled-plugin shards, channel contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Окремі ручні CI dispatch запускають Android лише з `include_android=true`; повна release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, повний extension batch sweep і plugin prerelease Docker lanes виключені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` dispatch окремого workflow `Plugin Prerelease` з увімкненим release-validation gate. -Manual runs використовують унікальну concurrency group, тому release-candidate full suite не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає trusted caller змогу запускати цей graph проти branch, tag або full commit SHA, використовуючи workflow file з вибраного dispatch ref. +Ручні запуски використовують унікальну concurrency group, тому повний suite реліз-кандидата не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає довіреному викликачеві змогу запустити цей граф для branch, tag або повного commit SHA, використовуючи workflow file з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -81,15 +81,15 @@ gh workflow run full-release-validation.yml --ref main -f ref= | Виконавець | Завдання | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/вбудованого пакета, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди й агрегати `check-additional`, агрегатні верифікатори тестів Node, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke також використовує Ubuntu, розміщену на GitHub, щоб матриця Blacksmith могла ставати в чергу раніше | -| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші шарди Plugins, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів вбудованих Plugins, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, тож 8 vCPU коштували більше, ніж заощаджували); Docker-збірки install-smoke (час очікування в черзі для 32 vCPU коштував більше, ніж заощаджував) | +| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/вбудованих компонентів, сегментовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегати `check-additional`, верифікатори агрегатів тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; попередня перевірка install-smoke також використовує Ubuntu, розміщений на GitHub, щоб матриця Blacksmith могла ставати в чергу раніше | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші шарди розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів вбудованих плагінів, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, тому 8 vCPU коштували дорожче, ніж заощаджували); Docker-збірки install-smoke (час у черзі для 32-vCPU коштував дорожче, ніж заощаджував) | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | | `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; форки повертаються до `macos-latest` | | `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки повертаються до `macos-latest` | -## Локальні еквіваленти +## Локальні відповідники ```bash pnpm changed:lanes # inspect the local changed-lane classifier for origin/main...HEAD @@ -115,35 +115,37 @@ pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-per pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json ``` -## Повна валідація релізу +## Повна перевірка релізу -`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного доказу Plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker release-path, live/E2E, OpenWebUI, паритету QA Lab, Matrix і ліній Telegram. Він також може запускати післяпублікаційний workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета. +`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного підтвердження плагінів/пакетів/статичних ресурсів/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів release-path Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` з артефактом `release-package-under-test` із перевірок релізу. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm-пакета. -Див. [Повну валідацію релізу](/uk/reference/full-release-validation) для +Див. [Повна перевірка релізу](/uk/reference/full-release-validation) для матриці етапів, точних назв завдань workflow, відмінностей профілів, артефактів і -цільових ідентифікаторів повторного запуску. +дескрипторів цільового повторного запуску. -`release_profile` керує широтою live/provider, що передається в release checks. Ручні release workflows за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли навмисно потрібна широка рекомендаційна матриця provider/media. +`release_profile` керує широтою live/provider, переданою в перевірки релізу. Ручні +релізні workflow типово використовують `stable`; використовуйте `full` лише тоді, коли +навмисно потрібна широка дорадча матриця провайдерів/медіа. -- `minimum` залишає найшвидші критичні для релізу лінії OpenAI/core. +- `minimum` залишає найшвидші критичні для релізу OpenAI/core lanes. - `stable` додає стабільний набір provider/backend. -- `full` запускає широку рекомендаційну матрицю provider/media. +- `full` запускає широку дорадчу матрицю провайдерів/медіа. -Парасолька записує ідентифікатори запущених дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього запуску. Якщо дочірній workflow повторно запущено і він стає зеленим, повторно запустіть лише батьківське завдання verifier, щоб оновити результат парасольки та підсумок часу. +Парасолька записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено й він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат парасольки та підсумок часу. -Для відновлення `Full Release Validation` і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для release candidate, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього plugin prerelease, `release-checks` для кожної дочірньої релізної перевірки або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` або `npm-telegram` у парасольці. Це утримує повторний запуск невдалої release box у межах після цільового виправлення. +Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата на реліз, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього prerelease плагінів, `release-checks` для кожного дочірнього релізного workflow або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це зберігає повторний запуск невдалої релізної машини обмеженим після цільового виправлення. -`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E Docker workflow release-path, і в shard package acceptance. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. +`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E release-path Docker workflow, і в шард package acceptance. Це зберігає байти пакета узгодженими між релізними машинами й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. -Дублікати запусків `Full Release Validation` для `ref=main` і `rerun_group=all` -витісняють старішу парасольку. Батьківський monitor скасовує будь-який дочірній workflow, який -він уже запустив, коли батьківський запуск скасовано, тож новіша валідація main -не очікує за застарілим двогодинним запуском release-check. Валідація release branch/tag -і цільові групи повторного запуску зберігають `cancel-in-progress: false`. +Дублікати прогонів `Full Release Validation` для `ref=main` і `rerun_group=all` +замінюють старішу парасольку. Батьківський монітор скасовує будь-який дочірній workflow, який +він уже запустив, коли батьківський workflow скасовано, тому новіша перевірка main +не стоїть позаду застарілого двогодинного прогону release-check. Перевірка релізної гілки/тега +й цільові групи повторного запуску залишають `cancel-in-progress: false`. ## Live та E2E шарди -Дочірній release live/E2E зберігає широке покриття нативного `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання: +Дочірній live/E2E для релізу зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання: - `native-live-src-agents` - `native-live-src-gateway-core` @@ -155,61 +157,61 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- розділені audio/video media shards і music shards, відфільтровані за provider +- розділені шарди audio/video для медіа та шарди music, відфільтровані за provider -Це зберігає те саме файлове покриття, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агрегатні назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків. +Це зберігає те саме файлове покриття, водночас спрощуючи повторний запуск і діагностику повільних live-збоїв provider. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків. -Нативні live media shards запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють бінарні файли перед setup. Тримайте live suites на базі Docker на звичайних runners Blacksmith — container jobs є неправильним місцем для запуску вкладених Docker tests. +Нативні live media шарди виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; медіа-завдання лише перевіряють двійкові файли перед налаштуванням. Тримайте Docker-backed live suites на звичайних виконавцях Blacksmith — container jobs є неправильним місцем для запуску вкладених Docker-тестів. -Live model/backend shards на базі Docker використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live release workflow один раз збирає та публікує цей образ, а потім Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness shards запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker shards мають явні обмеження `timeout` на рівні скриптів нижче за timeout завдання workflow, щоб завислий контейнер або шлях cleanup швидко завершувався помилкою, а не споживав увесь бюджет release-check. Якщо ці shards самостійно перебудовують повну ціль source Docker, release run налаштовано неправильно, і він марнуватиме wall clock на дубльовані збірки образів. +Docker-backed live model/backend шарди використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live release workflow збирає й публікує цей образ один раз, після чого Docker live model, provider-sharded gateway, CLI backend, ACP bind і шарди Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker шарди мають явні обмеження `timeout` на рівні скриптів нижче за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко падав, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, релізний прогін налаштовано неправильно, і він марнуватиме реальний час на дублікати збірок образів. ## Package Acceptance -Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей інстальований пакет OpenClaw як продукт?» Він відрізняється від звичайного CI: звичайний CI перевіряє source tree, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі виконують після install або update. +Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі проходять після встановлення або оновлення. ### Завдання -1. `resolve_package` вивіряє `workflow_ref`, визначає одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує джерело, ref workflow, ref пакета, версію, SHA-256 і профіль у підсумку кроку GitHub. -2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Багаторазовий workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-гілки для цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, багаторазовий workflow готує пакет і спільні образи один раз, а потім розгортає ці гілки як паралельні цільові Docker-завдання з унікальними артефактами. -3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance визначив його; автономний dispatch Telegram усе ще може встановити опубліковану npm-специфікацію. -4. `summary` завершує workflow з помилкою, якщо визначення пакета, Docker acceptance або необов’язкова Telegram-гілка завершилися невдало. +1. `resolve_package` перевіряє `workflow_ref`, визначає одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, посилання workflow, посилання пакета, версію, SHA-256 і профіль у підсумку кроку GitHub. +2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-лінії для цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow один раз готує пакет і спільні образи, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами. +3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance визначив його; окремий запуск Telegram усе ще може встановити опубліковану специфікацію npm. +4. `summary` завершує workflow з помилкою, якщо визначення пакета, Docker-приймання або опційна лінія Telegram завершилися невдало. ### Джерела кандидатів -- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованих beta/stable. -- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Resolver отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або релізного тегу, встановлює залежності у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. +- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих beta/stable. +- `source=ref` пакує довірену гілку `package_ref`, тег або повний SHA коміту. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт доступний з історії гілки репозиторію або релізного тегу, встановлює залежності у відокремленому worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. - `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим. -- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його слід надавати для артефактів, поширених назовні. +- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` є опційним, але його варто надати для зовнішньо поширених артефактів. -Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/тестового каркаса, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає поточному тестовому каркасу змогу перевіряти старі довірені вихідні коміти без запуску старої логіки workflow. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/тестового harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старі довірені вихідні коміти без запуску старої логіки workflow. -### Профілі suite +### Профілі наборів - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload` - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `plugins-offline`, `plugin-update` - `product` — `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full` — повні фрагменти Docker release-path з OpenWebUI +- `full` — повні фрагменти Docker-шляху релізу з OpenWebUI - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom` -Профіль `package` використовує офлайн-покриття Plugin, щоб перевірка опублікованого пакета не залежала від доступності live ClawHub. Необов’язкова Telegram-гілка повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації збережено для автономних dispatch. +Профіль `package` використовує offline-покриття Plugin, щоб перевірка опублікованого пакета не залежала від live-доступності ClawHub. Опційна лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої специфікації npm збережено для окремих запусків. -Окрему політику тестування оновлень і Plugin, зокрема локальні команди, -Docker-гілки, вхідні параметри Package Acceptance, типові налаштування релізів і triage збоїв, -див. у [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). +Для спеціальної політики тестування оновлень і Plugin, включно з локальними командами, +Docker-лініями, вхідними параметрами Package Acceptance, типовими параметрами релізу та тріажем збоїв, +див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). -Релізні перевірки викликають Package Acceptance з `source=artifact`, підготовленим артефактом релізного пакета, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це утримує перевірки міграції пакета, оновлення, очищення застарілих залежностей Plugin, офлайн Plugin, plugin-update і Telegram на тому самому визначеному tarball пакета. Cross-OS релізні перевірки й далі покривають специфічні для ОС onboarding, installer і поведінку платформи; перевірку продукту package/update слід починати з Package Acceptance. Docker-гілка `published-upgrade-survivor` перевіряє один базовий опублікований пакет за запуск. У Package Acceptance визначений tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback опубліковану базову версію, за замовчуванням `openclaw@latest`; команди повторного запуску збійних гілок зберігають цю базову версію. Установіть `published_upgrade_survivor_baselines=release-history`, щоб розгорнути гілку в матрицю дедуплікованої історії: шість останніх stable-релізів, `2026.4.23` і останній stable-реліз до `2026-03-15`. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розгорнути ті самі базові версії за issue-подібними fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, шляхів журналів з tilde і застарілих коренів залежностей legacy Plugin. Локальні агреговані запуски можуть передавати точні специфікації пакетів через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, лишати одну гілку з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або задавати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для матриці сценаріїв. Опублікована гілка налаштовує базову версію за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC-статус після запуску Gateway. Windows-гілки packaged і installer fresh також перевіряють, що встановлений пакет може імпортувати browser-control override з сирого абсолютного Windows-шляху. Cross-OS agent-turn smoke для OpenAI за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо встановлено, інакше `openai/gpt-5.5`, щоб докази встановлення й Gateway лишалися на бажаній GPT-5 тестовій моделі. +Перевірки релізу викликають Package Acceptance з `source=artifact`, підготовленим артефактом релізного пакета, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це зберігає перевірку міграції пакета, оновлення, очищення застарілих залежностей Plugin, offline Plugin, plugin-update і Telegram на одному й тому самому визначеному tarball пакета. Cross-OS перевірки релізу й надалі покривають специфічні для ОС onboarding, installer і поведінку платформи; перевірка продукту для пакета/оновлення має починатися з Package Acceptance. Docker-лінія `published-upgrade-survivor` перевіряє один baseline опублікованого пакета за запуск. У Package Acceptance визначений tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback baseline опублікованого пакета, за замовчуванням `openclaw@latest`; команди повторного запуску лінії, що впала, зберігають цей baseline. Установіть `published_upgrade_survivor_baselines=release-history`, щоб розширити лінію на дедупліковану матрицю історії: шість останніх stable-релізів, `2026.4.23` і останній stable-реліз перед `2026-03-15`. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-подібні fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, шляхів логів із тильдою та застарілих коренів залежностей legacy Plugin. Локальні агреговані запуски можуть передавати точні специфікації пакетів через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, залишати одну лінію з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для матриці сценаріїв. Опублікована лінія налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також статус RPC після старту Gateway. Лінії Windows packaged і installer fresh також перевіряють, що встановлений пакет може імпортувати browser-control override із сирого абсолютного шляху Windows. Smoke OpenAI cross-OS agent-turn за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо його встановлено, інакше `openai/gpt-5.5`, тож перевірка встановлення й gateway лишається на бажаній тестовій моделі GPT-5. -### Вікна сумісності з legacy +### Вікна legacy-сумісності Package Acceptance має обмежені вікна legacy-сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності: -- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть указувати на файли, пропущені в tarball; -- `doctor-switch` може пропустити підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець; -- `update-channel-switch` може прибрати відсутні `pnpm.patchedDependencies` із fake git fixture, отриманого з tarball, і може логувати відсутній збережений `update.channel`; -- plugin smokes можуть читати legacy-розташування install-record або приймати відсутнє збереження marketplace install-record; -- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас усе ще вимагаючи, щоб install record і поведінка no-reinstall лишалися незмінними. +- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball; +- `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець; +- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` із фіктивного git fixture, похідного від tarball, і може логувати відсутній збережений `update.channel`; +- smoke-перевірки Plugin можуть читати legacy-розташування install-record або приймати відсутнє збереження marketplace install-record; +- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас усе ще вимагаючи, щоб install record і поведінка без повторного встановлення лишалися незмінними. -Опублікований пакет `2026.4.26` також може попереджати про локальні файли штампів build metadata, які вже були відвантажені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою замість попередження або пропуску. +Опублікований пакет `2026.4.26` також може попереджати про файли stamp локальних build-метаданих, які вже були доставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови призводять до помилки замість попередження або пропуску. ### Приклади @@ -252,111 +254,111 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску package acceptance почніть із підсумку `resolve_package`, щоб підтвердити джерело пакета, версію і SHA-256. Потім перегляньте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали гілок, timings фаз і команди повторного запуску. Надавайте перевагу повторному запуску збійного профілю пакета або точних Docker-гілок замість повторного запуску повної релізної перевірки. +Під час налагодження невдалого запуску package acceptance починайте з підсумку `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перегляньте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, логи ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску профілю пакета, що впав, або точних Docker-ліній замість повторного запуску повної перевірки релізу. ## Install smoke Окремий workflow `Install Smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. -- **Швидкий шлях** запускається для pull requests, що зачіпають Docker/package surfaces, зміни package/manifest bundled Plugin або surfaces core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише вихідного коду bundled Plugin, правки лише тестів і правки лише документації не резервують Docker workers. Швидкий шлях один раз збирає root Dockerfile image, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо). -- **Повний шлях** зберігає QR package install і installer Docker/update coverage для нічних scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді зачіпають installer/package/Docker surfaces. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і fast bundled-plugin Docker E2E як окремі завдання, щоб робота installer не чекала за root image smokes. +- **Швидкий шлях** запускається для pull requests, що торкаються Docker/package-поверхонь, змін пакета/маніфесту bundled Plugin або core-поверхонь plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише вихідного коду bundled Plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає smoke CLI для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо). +- **Повний шлях** зберігає покриття QR package install і installer Docker/update для нічних планових запусків, ручних запусків, workflow-call перевірок релізу та pull requests, які справді торкаються installer/package/Docker-поверхонь. У повному режимі install-smoke готує або повторно використовує один GHCR root Dockerfile smoke-образ для target-SHA, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб installer-робота не чекала за smoke-перевірками root image. -Push у `main` (зокрема merge commits) не примушує повний шлях; коли логіка changed-scope запитувала б повне покриття на push, workflow зберігає швидкий Docker smoke і лишає повний install smoke для нічної або релізної перевірки. +Push до `main` (зокрема merge commits) не примушують повний шлях; коли логіка changed-scope вимагала б повного покриття на push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної перевірки. -Повільний Bun global install image-provider smoke окремо керується `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow релізних перевірок, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull requests і push у `main` не роблять цього. QR і installer Docker tests зберігають власні install-focused Dockerfiles. +Повільний smoke image-provider для глобального встановлення Bun окремо контролюється `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow перевірок релізу, а ручні запуски `Install Smoke` можуть увімкнути його, але pull requests і push до `main` — ні. QR і installer Docker-тести зберігають власні install-focused Dockerfiles. ## Локальний Docker E2E -`pnpm test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: +`pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: -- bare Node/Git runner для гілок installer/update/plugin-dependency; -- functional image, який встановлює той самий tarball у `/app` для гілок звичайної функціональності. +- bare Node/Git runner для ліній installer/update/plugin-dependency; +- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній. -Визначення Docker-гілок містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка planner — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Scheduler вибирає image для кожної гілки через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає гілки з `OPENCLAW_SKIP_DOCKER_BUILD=1`. +Визначення Docker-ліній розміщені в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`. ### Налаштування -| Змінна | За замовчуванням | Призначення | -| -------------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних смуг. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів хвостового пулу, чутливого до провайдерів. | -| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Обмеження одночасних live-смуг, щоб провайдери не застосовували throttling. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Обмеження одночасних смуг встановлення npm. | -| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Обмеження одночасних багатосервісних смуг. | -| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами смуг, щоб уникнути штормів створення в Docker daemon; установіть `0`, щоб вимкнути затримку. | -| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний тайм-аут для кожної смуги (120 хвилин); вибрані live/хвостові смуги використовують жорсткіші обмеження. | -| `OPENCLAW_DOCKER_ALL_DRY_RUN` | не встановлено | `1` друкує план планувальника без запуску смуг. | -| `OPENCLAW_DOCKER_ALL_LANES` | не встановлено | Розділений комами точний список смуг; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу смугу. | +| Змінна | Типове значення | Призначення | +| -------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------- | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних ліній. | +| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів хвостового пулу, чутливого до провайдерів. | +| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live-ліній, щоб провайдери не вмикали обмеження. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних ліній встановлення npm. | +| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних багатосервісних ліній. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між запусками ліній, щоб уникнути штормів створення в демоні Docker; задайте `0`, щоб вимкнути затримку. | +| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний тайм-аут для кожної лінії (120 хвилин); вибрані live/хвостові лінії використовують жорсткіші ліміти. | +| `OPENCLAW_DOCKER_ALL_DRY_RUN` | не задано | `1` друкує план планувальника без запуску ліній. | +| `OPENCLAW_DOCKER_ALL_LANES` | не задано | Розділений комами точний список ліній; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу лінію. | -Смуга, важча за свій ефективний ліміт, усе одно може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальний агрегатор виконує попередні перевірки Docker, видаляє застарілі OpenClaw E2E-контейнери, виводить статус активних смуг, зберігає тривалості смуг для впорядкування від найдовших до найкоротших і за замовчуванням припиняє планувати нові pooled-смуги після першого збою. +Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім виконується сама, доки не звільнить місткість. Локальний агрегатор попередньо перевіряє Docker, видаляє застарілі OpenClaw E2E-контейнери, виводить статус активних ліній, зберігає тривалості ліній для впорядкування від найдовших і типово припиняє планування нових pooled-ліній після першого збою. -### Повторно використовуваний live/E2E workflow +### Багаторазовий live/E2E workflow -Повторно використовуваний live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, смуги та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє inventory tarball; збирає й публікує позначені digest пакета bare/functional GHCR Docker E2E-образи через Docker layer cache Blacksmith, коли план потребує смуг із установленим пакетом; і повторно використовує надані входи `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи з digest пакета замість повторної збірки. Завантаження Docker-образів повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторився, а не спожив більшість критичного шляху CI. +Багаторазовий live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, які пакет, тип образу, live-образ, лінія та покриття обліковими даними потрібні. `scripts/docker-e2e.mjs` потім перетворює цей план на виходи й підсумки GitHub. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та публікує bare/functional GHCR Docker E2E-образи з тегами package-digest через кеш Docker-шарів Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані входи `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи package-digest замість повторного збирання. Завантаження Docker-образів повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторився, а не спожив більшість критичного шляху CI. -### Фрагменти release-path +### Фрагменти release-шляху -Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент завантажував лише потрібний йому тип образу й виконував кілька смуг через той самий зважений планувальник: +Release Docker-покриття запускає менші фрагментовані job з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент завантажував лише потрібний тип образу й виконував кілька ліній через той самий зважений планувальник: - `OPENCLAW_DOCKER_ALL_PROFILE=release-path` - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h` -Поточні release Docker-фрагменти: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами plugin/runtime. Псевдонім смуги `install-e2e` залишається агрегованим ручним псевдонімом повторного запуску для обох смуг встановлювачів провайдерів. +Поточні release Docker-фрагменти: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і `plugins-runtime-install-a` through `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається агрегованим псевдонімом ручного повторного запуску для обох ліній installer провайдера. -OpenWebUI включається до `plugins-runtime-services`, коли цього вимагає повне release-path coverage, і зберігає окремий фрагмент `openwebui` лише для dispatch, що стосується тільки OpenWebUI. Смуги оновлення bundled-channel один раз повторюють запуск у разі тимчасових мережевих збоїв npm. +OpenWebUI включається до `plugins-runtime-services`, коли повне release-path-покриття його запитує, і зберігає окремий фрагмент `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Лінії оновлення bundled-channel повторюють спробу один раз у разі тимчасових мережевих збоїв npm. -Кожен фрагмент завантажує `.artifacts/docker-tests/` із журналами смуг, тривалостями, `summary.json`, `failures.json`, тривалостями фаз, JSON-планом планувальника, таблицями повільних смуг і командами повторного запуску для кожної смуги. Вхід workflow `docker_lanes` запускає вибрані смуги проти підготовлених образів замість chunk jobs, що обмежує налагодження невдалої смуги одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана смуга є live Docker-смугою, цільовий job локально збирає live-test образ для цього повторного запуску. Згенеровані для кожної смуги команди повторного запуску GitHub містять `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, щоб невдала смуга могла повторно використати саме той пакет і образи з невдалого запуску. +Кожен фрагмент вивантажує `.artifacts/docker-tests/` з логами ліній, тривалостями, `summary.json`, `failures.json`, тривалостями фаз, JSON-планом планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Вхід `docker_lanes` workflow запускає вибрані лінії проти підготовлених образів замість fragment jobs, що обмежує налагодження невдалої лінії одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker-лінією, цільовий job збирає live-test-образ локально для цього повторного запуску. Згенеровані команди GitHub для повторного запуску кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і підготовлені входи образів, коли такі значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску. ```bash -pnpm test:docker:rerun # завантажити Docker-артефакти й надрукувати об’єднані/посмугові цільові команди повторного запуску -pnpm test:docker:timings # зведення повільних смуг і критичного шляху фаз +pnpm test:docker:rerun # download Docker artifacts and print combined/per-lane targeted rerun commands +pnpm test:docker:timings # slow-lane and phase critical-path summaries ``` -Запланований live/E2E workflow щодня запускає повний release-path Docker suite. +Запланований live/E2E workflow щодня запускає повний Docker-набір release-path. -## Plugin Prerelease +## Попередній випуск Plugin -`Plugin Prerelease` — дорожче покриття продукту/пакета, тому це окремий workflow, який запускає `Full Release Validation` або явний оператор. Звичайні pull requests, пуші в `main` і автономні ручні CI dispatches не запускають цей suite. Він балансує тести bundled plugin між вісьмома extension workers; ці extension shard jobs запускають до двох груп конфігурації plugin одночасно з одним Vitest worker на групу й більшим Node heap, щоб насичені імпортами batches plugin не створювали додаткові CI jobs. Release-only Docker prerelease path групує цільові Docker-смуги в невеликі групи, щоб не резервувати десятки runners для jobs тривалістю від однієї до трьох хвилин. +`Plugin Prerelease` є дорожчим продуктово-пакетним покриттям, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push у `main` і самостійні ручні CI dispatch не вмикають цей набір. Він балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох груп конфігурацій Plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети Plugin не створювали додаткових CI jobs. Release-only Docker prerelease path групує цільові Docker-лінії в малі групи, щоб не резервувати десятки runners для job тривалістю від однієї до трьох хвилин. ## QA Lab -QA Lab має виділені CI-смуги поза основним smart-scoped workflow. +QA Lab має виділені CI-лінії поза основним smart-scoped workflow. -- Workflow `Parity gate` запускається для відповідних змін PR і ручного dispatch; він збирає приватний QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6. -- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через ручний dispatch; він розгортає mock parity gate, live Matrix-смугу, а також live Telegram і Discord-смуги як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. +- Workflow `Parity gate` запускається на відповідних змінах PR і ручному dispatch; він збирає приватний QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6. +- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і вручну через dispatch; він розгортає mock parity gate, live Matrix lane і live Telegram та Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. -Release checks запускають Matrix і Telegram live transport lanes із deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` та `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live-моделі та звичайного старту provider-plugin. Live transport gateway вимикає memory search, бо QA parity окремо покриває поведінку пам’яті; підключення провайдера покривають окремі suites live model, native provider і Docker provider. +Release checks запускають live transport lanes Matrix і Telegram із детермінованим mock-провайдером та mock-qualified моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від live model latency і звичайного startup provider-plugin. Live transport gateway вимикає пошук памʼяті, бо QA parity окремо покриває поведінку памʼяті; підключення провайдера покривається окремими наборами live model, native provider і Docker provider. -Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI це підтримує. CLI default і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. +Matrix використовує `--profile fast` для запланованих і release gates, додаючи `--fail-fast` лише коли checkout CLI це підтримує. Типове значення CLI та вхід ручного workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix-покриття на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. -`OpenClaw Release Checks` також запускає критичні для релізу QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невеликий report job для фінального parity comparison. +`OpenClaw Release Checks` також запускає критичні для release лінії QA Lab перед затвердженням release; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в малий report job для фінального parity comparison. -Не ставте PR landing path за `Parity gate`, якщо зміна фактично не торкається QA runtime, model-pack parity або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit tests вважайте це необов’язковим сигналом і спирайтеся на scoped CI/check evidence. +Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не зачіпає QA runtime, model-pack parity або поверхню, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-test розглядайте це як optional signal і спирайтеся на scoped CI/check evidence. ## CodeQL -Workflow `CodeQL` навмисно є вузьким первинним security scanner, а не повним repository sweep. Щоденні, ручні й non-draft pull request guard runs сканують Actions workflow code плюс JavaScript/TypeScript-поверхні найвищого ризику з high-confidence security queries, відфільтрованими до high/critical `security-severity`. +Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep репозиторію. Щоденні, ручні та non-draft pull request guard runs сканують код Actions workflow плюс JavaScript/TypeScript-поверхні найвищого ризику за допомогою high-confidence security queries, відфільтрованих до high/critical `security-severity`. -Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL не входять до PR defaults. +Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й запланований workflow. Android і macOS CodeQL не входять до типових PR-запусків. ### Категорії безпеки -| Категорія | Поверхня | -| ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | +| Категорія | Поверхня | +| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron і gateway baseline | -| `/codeql-security-high/channel-runtime-boundary` | Контракти core channel implementation плюс channel plugin runtime, gateway, Plugin SDK, secrets, audit touchpoints | -| `/codeql-security-high/network-ssrf-boundary` | Core SSRF, IP parsing, network guard, web-fetch і поверхні Plugin SDK SSRF policy | -| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, process execution helpers, outbound delivery і agent tool-execution gates | -| `/codeql-security-high/plugin-trust-boundary` | Plugin install, loader, manifest, registry, package-manager install, source-loading і trust-поверхні Plugin SDK package contract | +| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації core channel плюс channel plugin runtime, gateway, Plugin SDK, secrets, audit touchpoints | +| `/codeql-security-high/network-ssrf-boundary` | Core SSRF, IP parsing, network guard, web-fetch і поверхні політики SSRF у Plugin SDK | +| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, process execution helpers, outbound delivery і agent tool-execution gates | +| `/codeql-security-high/plugin-trust-boundary` | Plugin install, loader, manifest, registry, package-manager install, source-loading і trust surfaces контракту package у Plugin SDK | ### Платформоспецифічні security shards -- `CodeQL Android Critical Security` — scheduled Android security shard. Збирає Android app вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує в `/codeql-critical-security/android`. -- `CodeQL macOS Critical Security` — weekly/manual macOS security shard. Збирає macOS app вручну для CodeQL на Blacksmith macOS, відфільтровує dependency build results із завантаженого SARIF і завантажує в `/codeql-critical-security/macos`. Залишається поза daily defaults, бо macOS build домінує runtime навіть у чистому стані. +- `CodeQL Android Critical Security` — запланований Android security shard. Збирає Android app вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Вивантажує під `/codeql-critical-security/android`. +- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Збирає macOS app вручну для CodeQL на Blacksmith macOS, відфільтровує результати dependency build з вивантаженого SARIF і вивантажує під `/codeql-critical-security/macos`. Тримається поза щоденними типовими запусками, бо macOS build домінує за runtime навіть коли чистий. ### Категорії Critical Quality -`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries на вузьких high-value surfaces на меншому Blacksmith Linux runner. Його pull request guard навмисно менший за scheduled profile: non-draft PRs запускають лише відповідні shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у коді agent command/model/tool execution і reply dispatch, config schema/migration/IO code, auth/secrets/sandbox/security code, core channel і bundled channel plugin runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або Plugin SDK reply runtime. Зміни CodeQL config і quality workflow запускають усі дванадцять PR quality shards. +`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries по вузьких high-value поверхнях на меншому Blacksmith Linux runner. Його pull request guard навмисно менший за запланований профіль: non-draft PRs запускають лише відповідні shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у коді виконання agent command/model/tool і reply dispatch, коді config schema/migration/IO, коді auth/secrets/sandbox/security, core channel і bundled channel plugin runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або Plugin SDK reply runtime. Зміни CodeQL config і quality workflow запускають усі дванадцять PR quality shards. Manual dispatch приймає: @@ -364,40 +366,40 @@ Manual dispatch приймає: profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary ``` -Вузькі profiles — це навчальні/ітераційні hooks для запуску одного quality shard ізольовано. +Вузькі профілі є hooks для навчання/ітерації, щоб запускати один quality shard ізольовано. -| Категорія | Поверхня | -| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | Код межі безпеки автентифікації, секретів, пісочниці, Cron і Gateway | -| `/codeql-critical-quality/config-boundary` | Схема конфігурації, міграція, нормалізація та контракти IO | -| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти методів сервера | -| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації основного каналу та вбудованого канального plugin | -| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, диспетчеризація моделі/провайдера, диспетчеризація автовідповідей і черги, а також runtime-контракти площини керування ACP | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | Сервери MCP і мости інструментів, допоміжні засоби нагляду за процесами та контракти вихідної доставки | -| `/codeql-critical-quality/memory-runtime-boundary` | SDK хоста памʼяті, runtime-фасади памʼяті, псевдоніми SDK памʼяті для Plugin, звʼязувальний код активації runtime памʼяті та команди doctor для памʼяті | -| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні компоненти черги відповідей, черги доставки сесій, допоміжні засоби привʼязування/доставки вихідних сесій, поверхні діагностичних подій/пакетів журналів і контракти CLI doctor для сесій | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей SDK Plugin, допоміжні засоби payload/поділу на фрагменти/runtime для відповідей, параметри відповідей каналів, черги доставки та допоміжні засоби привʼязування сесій/потоків | -| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація й виявлення провайдерів, реєстрація runtime провайдерів, стандартні значення/каталоги провайдерів і реєстри web/search/fetch/embedding | -| `/codeql-critical-quality/ui-control-plane` | Початкове завантаження UI керування, локальне збереження, потоки керування Gateway і runtime-контракти площини керування завданнями | -| `/codeql-critical-quality/web-media-runtime-boundary` | Runtime-контракти основного web fetch/search, media IO, розуміння медіа, генерування зображень і генерування медіа | -| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та точок входу SDK Plugin | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований вихідний код SDK Plugin на боці пакета та допоміжні засоби контракту пакета plugin | +| Категорія | Поверхня | +| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `/codeql-critical-quality/core-auth-secrets` | Auth, секрети, sandbox, Cron і код межі безпеки Gateway | +| `/codeql-critical-quality/config-boundary` | Схема конфігурації, міграція, нормалізація та контракти IO | +| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти серверних методів | +| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації основного каналу та bundled channel plugin | +| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація та черги автовідповідей, а також runtime-контракти control plane ACP | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | Сервери MCP і tool bridges, помічники нагляду за процесами та контракти outbound delivery | +| `/codeql-critical-quality/memory-runtime-boundary` | SDK хоста пам’яті, runtime-фасади пам’яті, псевдоніми memory Plugin SDK, glue-код активації memory runtime та команди memory doctor | +| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішня реалізація черги відповідей, черги доставки сесій, помічники прив’язки/доставки outbound-сесій, поверхні діагностичних подій/log bundle і контракти CLI session doctor | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей Plugin SDK, помічники payload/chunking/runtime відповідей, параметри відповідей каналів, черги доставки та помічники прив’язки сесій/потоків | +| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація та discovery провайдерів, реєстрація provider runtime, provider defaults/catalogs, а також реєстри web/search/fetch/embedding | +| `/codeql-critical-quality/ui-control-plane` | Bootstrap Control UI, локальна персистентність, control flows Gateway і runtime-контракти task control-plane | +| `/codeql-critical-quality/web-media-runtime-boundary` | Runtime-контракти core web fetch/search, media IO, media understanding, image-generation та media-generation | +| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, public-surface і entrypoint Plugin SDK | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований package-side вихідний код Plugin SDK і помічники контрактів package plugin | -Якість залишається окремою від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затінення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих plugin слід додавати назад як обмежену за областю або шардовану подальшу роботу лише після того, як вузькі профілі матимуть стабільні runtime і сигнал. +Якість залишається відокремленою від безпеки, щоб висновки щодо якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал. -## Робочі процеси супроводу +## Робочі процеси обслуговування -### Агент документації +### Docs Agent -Робочий процес `Docs Agent` — це подієво-керована лінія супроводу Codex для підтримання наявної документації у відповідності з нещодавно внесеними змінами. Вона не має чистого розкладу: успішний CI-запуск після push не від бота на `main` може її запустити, а ручний dispatch може запустити її напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший не пропущений запуск Docs Agent був створений протягом останньої години. Під час виконання вона переглядає діапазон комітів від попереднього не пропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з часу останнього проходу документації. +Робочий процес `Docs Agent` — це керована подіями maintenance lane Codex для підтримання наявної документації у відповідності з нещодавно доданими змінами. Він не має чистого розкладу: успішний CI-запуск після push не від bot на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший не пропущений запуск Docs Agent було створено протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього не пропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з останнього проходу документації. -### Агент продуктивності тестів +### Test Performance Agent -Робочий процес `Test Performance Agent` — це подієво-керована лінія супроводу Codex для повільних тестів. Вона не має чистого розкладу: успішний CI-запуск після push не від бота на `main` може її запустити, але вона пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього дня UTC. Ручний dispatch обходить це денне обмеження активності. Лінія будує згрупований звіт продуктивності Vitest для повного набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, що зменшують базову кількість тестів, які проходять. Якщо базовий стан має тести, що падають, Codex може виправляти лише очевидні збої, а звіт повного набору після агента має пройти до коміту будь-чого. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія перебазовує перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patch пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму drop-sudo позицію безпеки, що й агент документації. +Робочий процес `Test Performance Agent` — це керована подіями maintenance lane Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск після push не від bot на `main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей daily activity gate. Lane будує повний grouped Vitest performance report для всього набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, які зменшують baseline count успішних тестів. Якщо baseline має failing tests, Codex може виправити лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким commit. Коли `main` просувається до того, як bot push буде додано, lane rebases перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб action Codex міг зберегти ту саму drop-sudo safety posture, що й docs agent. -### Дублікати PR після злиття +### Дублікати PR після merge -Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес супроводжувача для очищення дублікатів після land. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR злитий і що кожен дублікат має або спільне згадане issue, або перекривні змінені hunks. +Робочий процес `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після land. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR merged і що кожен duplicate має або спільну referenced issue, або overlapping changed hunks. ```bash gh workflow run duplicate-after-merge.yml \ @@ -406,29 +408,29 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Локальні check-gates і маршрутизація змін +## Локальні check gates і changed routing -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широка область CI-платформи: +Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий scope платформи CI: -- зміни production-коду core запускають typecheck core prod і core test плюс core lint/guards; -- зміни лише тестів core запускають лише typecheck core test плюс core lint; -- зміни production-коду extension запускають typecheck extension prod і extension test плюс extension lint; -- зміни лише тестів extension запускають typecheck extension test плюс extension lint; -- зміни публічного SDK Plugin або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core-контрактів (прогони Vitest для extensions залишаються явною тестовою роботою); -- зміни лише release metadata для підняття версії запускають цільові перевірки версії/конфігурації/root-залежностей; -- невідомі зміни root/config fail safe до всіх check lanes. +- core production changes запускають core prod і core test typecheck плюс core lint/guards; +- core test-only changes запускають лише core test typecheck плюс core lint; +- extension production changes запускають extension prod і extension test typecheck плюс extension lint; +- extension test-only changes запускають extension test typecheck плюс extension lint; +- public Plugin SDK або plugin-contract changes розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються explicit test work); +- release metadata-only version bumps запускають targeted version/config/root-dependency checks; +- unknown root/config changes fail safe до всіх check lanes. -Локальна маршрутизація changed-test міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі правки тестів запускають самі себе, правки джерел віддають перевагу явним мапінгам, потім sibling tests і залежним з import graph. Конфігурація доставки shared group-room є одним з явних мапінгів: зміни до конфігурації group visible-reply, режиму доставки source reply або системного prompt message-tool проходять через основні тести відповідей плюс регресії доставки Discord і Slack, щоб зміна shared default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки широка для harness, що дешевий змapped набір не є надійним proxy. +Локальний changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі edits тестів запускають самі себе, source edits віддають перевагу explicit mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config — одне з explicit mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс Discord і Slack delivery regressions, щоб shared default change зазнав failure перед першим PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли change достатньо harness-wide, що дешевий mapped set не є надійним proxy. -## Валідація Testbox +## Перевірка Testbox -Запускайте Testbox з кореня репозиторію й надавайте перевагу свіжій прогрітій box для широкого proof. Перед витрачанням повільного gate на box, яку повторно використали, термін якої минув або яка щойно повідомила про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині box. +Запускайте Testbox з repo root і віддавайте перевагу свіжому warmed box для broad proof. Перш ніж витрачати повільний gate на box, який було reused, expired або який щойно повідомив про неочікувано великий sync, спочатку запустіть `pnpm testbox:sanity` всередині box. -Sanity check швидко падає, коли зникли потрібні root-файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що стан remote sync не є надійною копією PR; зупиніть цю box і прогрійте свіжу замість налагодження збою product test. Для PR з навмисними великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run. +Sanity check fails fast, коли обов’язкові root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною копією PR; зупиніть цей box і warm a fresh one замість налагодження product test failure. Для навмисних large-deletion PR встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run. -`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі sync понад пʼять хвилин без post-sync output. Встановіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих локальних diff. +`pnpm testbox:run` також завершує локальний Blacksmith CLI invocation, який залишається у sync phase понад п’ять хвилин без post-sync output. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих local diffs. -Crabbox — це другий remote-box шлях, яким володіє репозиторій, для proof на Linux, коли Blacksmith недоступний або коли бажаніша власна хмарна потужність. Прогрійте box, гідруйте її через workflow проєкту, а потім запускайте команди через Crabbox CLI: +Crabbox — це repo-owned другий remote-box path для Linux proof, коли Blacksmith недоступний або коли owned cloud capacity є кращою. Warm a box, hydrate його через project workflow, потім запускайте команди через Crabbox CLI: ```bash pnpm crabbox:warmup -- --idle-timeout 90m @@ -437,9 +439,9 @@ pnpm crabbox:run -- --id --shell "OPENCLAW_TESTBOX=1 pnpm check:changed pnpm crabbox:stop -- ``` -`.crabbox.yaml` визначає стандартні значення provider, sync і GitHub Actions hydration. Він виключає локальний `.git`, щоб hydrated checkout Actions зберігав власні remote Git metadata замість синхронізації maintainer-local remotes і object stores, а також виключає локальні runtime/build artifacts, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` визначає checkout, налаштування Node/pnpm, fetch `origin/main` і non-secret environment handoff, який пізніші команди `crabbox run --id ` підвантажують як source. +`.crabbox.yaml` керує provider, sync і GitHub Actions hydration defaults. Він виключає локальний `.git`, щоб hydrated Actions checkout зберігав власні remote Git metadata замість syncing maintainer-local remotes і object stores, а також виключає local runtime/build artifacts, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` керує checkout, налаштуванням Node/pnpm, fetch `origin/main` і non-secret environment handoff, який пізніші команди `crabbox run --id ` source. -## Повʼязане +## Пов’язане - [Огляд встановлення](/uk/install) - [Канали розробки](/uk/install/development-channels) diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index 60e88a06c..fb0152a24 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -1,162 +1,246 @@ --- read_when: - - Пошук визначень публічних каналів випуску - - Запуск перевірки релізу або приймального тестування пакета - - Шукаєте правила іменування версій і ритм випусків -summary: Релізні лінії, контрольний список оператора, валідаційні середовища, іменування версій і каденс + - Пошук визначень публічних каналів релізів + - Запуск валідації релізу або приймання пакета + - Шукаєте правила найменування версій і ритм випусків +summary: Канали релізу, контрольний список оператора, середовища перевірки, іменування версій і періодичність title: Політика випусків x-i18n: - generated_at: "2026-05-01T22:37:27Z" + generated_at: "2026-05-01T23:10:04Z" model: gpt-5.5 provider: openai - source_hash: 6ebbb0f42ee5f1ea29eb3133fcef7c829f855f5d668d8b8af373a6e148bb56ee + source_hash: 89274e9cbd5546b718517053e37574ceae53d4031d6ec02a033d250908e93bfd source_path: reference/RELEASING.md workflow: 16 --- -OpenClaw має три публічні канали релізів: +OpenClaw має три публічні канали випусків: -- stable: позначені тегами релізи, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано -- beta: передрелізні теги, які публікуються в npm `beta` -- dev: рухома верхівка `main` +- стабільний: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано +- бета: передрелізні теги, які публікуються в npm `beta` +- розробницький: рухома вершина `main` ## Назви версій -- Версія стабільного релізу: `YYYY.M.D` +- Версія стабільного випуску: `YYYY.M.D` - Git-тег: `vYYYY.M.D` -- Версія корекційного стабільного релізу: `YYYY.M.D-N` +- Версія стабільного корекційного випуску: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія beta-передрелізу: `YYYY.M.D-beta.N` +- Версія бета-передрелізу: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` -- Не доповнюйте місяць або день нулем на початку -- `latest` означає поточний просунутий стабільний npm-реліз -- `beta` означає поточну ціль встановлення beta -- Стабільні та корекційні стабільні релізи типово публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або просунути перевірену beta-збірку пізніше -- Кожен стабільний реліз OpenClaw постачає npm-пакет і macOS-застосунок разом; - beta-релізи зазвичай спершу перевіряють і публікують шлях npm/пакета, а - збирання/підписування/нотаризація mac-застосунку резервуються для стабільного релізу, якщо їх не запитано явно +- Не додавайте початкові нулі до місяця або дня +- `latest` означає поточний просунутий стабільний npm-випуск +- `beta` означає поточну ціль бета-встановлення +- Стабільні та стабільні корекційні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або просунути перевірену бета-збірку пізніше +- Кожен стабільний випуск OpenClaw постачає npm-пакет і застосунок macOS разом; + бета-випуски зазвичай спершу перевіряють і публікують шлях npm/пакета, а + збирання/підпис/нотаризація застосунку Mac зарезервовані для стабільних випусків, якщо це явно не запитано -## Частота релізів +## Частота випусків -- Релізи рухаються за принципом beta-first -- Стабільний реліз іде лише після перевірки останньої beta -- Мейнтейнери зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної - з поточного `main`, щоб валідація релізу й виправлення не блокували нову +- Випуски рухаються спершу через бета-канал +- Стабільний випуск іде лише після перевірки останньої бети +- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної + з поточного `main`, щоб перевірка випуску та виправлення не блокували нову розробку в `main` -- Якщо beta-тег уже було надіслано або опубліковано і він потребує виправлення, мейнтейнери створюють - наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега -- Детальна процедура релізу, погодження, облікові дані та нотатки з відновлення - доступні лише мейнтейнерам +- Якщо бета-тег уже було надіслано або опубліковано й він потребує виправлення, супровідники створюють + наступний тег `-beta.N` замість видалення або повторного створення старого бета-тега +- Детальна процедура випуску, затвердження, облікові дані та примітки з відновлення + доступні лише супровідникам -## Контрольний список оператора релізу +## Контрольний список оператора випуску -Цей контрольний список описує публічну форму процесу релізу. Приватні облікові дані, -підписування, нотаризація, відновлення dist-tag і подробиці аварійного відкату залишаються в -релізному runbook, доступному лише мейнтейнерам. +Цей контрольний список показує публічну форму процесу випуску. Приватні облікові дані, +підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються в +інструкції випуску лише для супровідників. -1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано, - і переконайтеся, що поточний CI для `main` достатньо зелений, щоб створювати від нього гілку. +1. Почніть із поточного `main`: завантажте останні зміни, підтвердьте, що цільовий коміт надіслано, + і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку. 2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою - `/changelog`, залиште записи орієнтованими на користувачів, закомітьте його, надішліть і виконайте rebase/pull - ще раз перед створенням гілки. -3. Перегляньте записи сумісності релізу в + `/changelog`, залишайте записи орієнтованими на користувача, закомітьте це, надішліть і ще раз виконайте rebase/pull + перед створенням гілки. +3. Перегляньте записи сумісності випуску в `src/plugins/compat/registry.ts` і `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її - навмисно зберігають. -4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над релізом + навмисно збережено. +4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском безпосередньо в `main`. -5. Оновіть усі необхідні місця з версією для запланованого тега, потім запустіть - локальний детермінований preflight: +5. Підніміть версію в усіх потрібних місцях для запланованого тега, а потім запустіть + локальну детерміновану попередню перевірку: `pnpm check:test-types`, `pnpm check:architecture`, `pnpm build && pnpm ui:build` і `pnpm release:check`. -6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До створення тега - повний 40-символьний SHA релізної гілки дозволений для validation-only - preflight. Збережіть успішний `preflight_run_id`. -7. Запустіть усі передрелізні тести через `Full Release Validation` для - релізної гілки, тега або повного SHA коміту. Це єдина ручна точка входу - для чотирьох великих релізних тестових боксів: Vitest, Docker, QA Lab і Package. -8. Якщо валідація не проходить, виправте в релізній гілці та повторно запустіть найменший невдалий - файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що - доводить виправлення. Повторно запускайте повний umbrella лише тоді, коли змінена поверхня робить +6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега + для попередньої перевірки лише з метою валідації дозволено повний 40-символьний SHA гілки випуску. + Збережіть успішний `preflight_run_id`. +7. Запустіть усі передрелізні тести за допомогою `Full Release Validation` для + гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу + для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package. +8. Якщо перевірка не проходить, виправте в гілці випуску та повторно запустіть найменший невдалий + файл, канал, завдання workflow, профіль пакета, провайдера або список дозволених моделей, який + доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить попередні докази застарілими. -9. Для beta позначте тегом `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть - package acceptance після публікації проти опублікованого пакета `openclaw@YYYY.M.D-beta.N` - або `openclaw@beta`. Якщо надіслана або опублікована beta потребує виправлення, створіть - наступний `-beta.N`; не видаляйте й не переписуйте стару beta. -10. Для стабільного релізу продовжуйте лише після того, як перевірена beta або release candidate матиме - необхідні докази валідації. Публікація стабільного npm повторно використовує успішний - preflight-артефакт через `preflight_run_id`; готовність стабільного macOS-релізу - також вимагає запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого +9. Для бети позначте тегом `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, а потім запустіть + post-publish приймання пакета проти опублікованого пакета `openclaw@YYYY.M.D-beta.N` + або `openclaw@beta`. Якщо надіслана або опублікована бета потребує виправлення, створіть + наступний `-beta.N`; не видаляйте й не переписуйте стару бету. +10. Для стабільного випуску продовжуйте лише після того, як перевірена бета або реліз-кандидат матиме + потрібні докази перевірки. Стабільна публікація npm повторно використовує успішний + артефакт попередньої перевірки через `preflight_run_id`; готовність стабільного випуску macOS + також потребує запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`. 11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний - опублікований-npm Telegram E2E, коли потрібен післяпублікаційний доказ каналу, - просування dist-tag за потреби, нотатки GitHub release/prerelease з - повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу. + опублікований-npm Telegram E2E, коли потрібен доказ каналу після публікації, + просування dist-tag за потреби, примітки GitHub release/prerelease з + повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску. -## Release preflight +## Попередня перевірка випуску -- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався покритим поза швидшим локальним шлюзом `pnpm check` -- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом -- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані релізні артефакти `dist/*` і пакет Control UI існували для кроку перевірки пакування -- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку, тег або повний SHA коміту, запускає ручний `CI` і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів release-path Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram lanes. Надавайте `npm_telegram_package_spec` лише після публікації пакета й коли післяпублікаційний Telegram E2E також має виконатися. Надавайте `evidence_package_spec`, коли приватний доказовий звіт має підтвердити, що перевірка відповідає опублікованому npm-пакету, без примусового запуску Telegram E2E. Приклад: +- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався + покритим поза швидшим локальним шлюзом `pnpm check` +- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів імпортів + і архітектурних меж були зеленими поза швидшим локальним шлюзом +- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані + релізні артефакти `dist/*` і пакет Control UI існували для кроку перевірки + пакування +- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб + запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку, + тег або повний SHA коміту, запускає ручний `CI` і запускає + `OpenClaw Release Checks` для install smoke, package acceptance, Docker + release-path наборів, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram + lanes. З `release_profile=full` і `rerun_group=all` він також запускає package + Telegram E2E для артефакта `release-package-under-test` з release + checks. Надайте `npm_telegram_package_spec` після публікації, коли той самий + Telegram E2E також має перевірити опублікований npm-пакет. Надайте + `evidence_package_spec`, коли приватний evidence report має підтвердити, що + валідація відповідає опублікованому npm-пакету без примусового Telegram E2E. + Приклад: `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D` -- Запустіть ручний workflow `Package Acceptance`, коли потрібен побічний доказ для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, щоб запакувати довірену гілку/тег/SHA `package_ref` із поточним harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub Actions. Workflow розв’язує кандидата до `package-under-test`, повторно використовує release scheduler Docker E2E проти цього tarball і може запускати Telegram QA проти того самого tarball з `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані Docker lanes містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а `published_upgrade_survivor_baseline` вибирає опубліковану базову версію. +- Запустіть ручний workflow `Package Acceptance`, коли потрібен side-channel доказ + для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для + `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, + щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним harness + `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим SHA-256; або + `source=artifact` для tarball, завантаженого іншим запуском GitHub + Actions. Workflow резолвить кандидата до + `package-under-test`, повторно використовує Docker E2E release scheduler для цього + tarball і може запускати Telegram QA для того самого tarball з + `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані + Docker lanes включають `published-upgrade-survivor`, артефакт пакета є кандидатом, а `published_upgrade_survivor_baseline` вибирає + опублікований baseline. Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai` Поширені профілі: - - `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації - - `package`: package/update/plugin lanes, нативні для артефакта, без OpenWebUI або live ClawHub - - `product`: профіль пакета плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI - - `full`: частини release-path Docker з OpenWebUI + - `smoke`: lanes для install/channel/agent, gateway network і config reload + - `package`: lanes для artifact-native package/update/plugin без OpenWebUI або live ClawHub + - `product`: профіль package плюс MCP-канали, очищення cron/субагентів, + OpenAI web search і OpenWebUI + - `full`: Docker release-path chunks з OpenWebUI - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску -- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI-покриття для реліз-кандидата. Ручні запуски CI обходять changed scoping і примусово запускають Linux Node shards, bundled-plugin shards, контракти каналів, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS, Android і Control UI i18n lanes. +- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI + покриття для релізного кандидата. Ручні запуски CI обходять changed + scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel + contracts, сумісність Node 22, `check`, `check-additional`, build smoke, + docs checks, Python skills, Windows, macOS, Android і Control UI i18n + lanes. Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D` -- Запустіть `pnpm qa:otel:smoke` під час перевірки релізної телеметрії. Він проганяє QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace span, обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse або іншому зовнішньому collector. -- Запускайте `pnpm release:check` перед кожним релізом із тегом -- Релізні перевірки тепер виконуються в окремому ручному workflow: +- Запустіть `pnpm qa:otel:smoke`, коли перевіряєте релізну телеметрію. Це проганяє + QA-lab через локальний OTLP/HTTP-приймач і перевіряє експортовані назви trace + span, обмежені атрибути та редагування вмісту/ідентифікаторів без + потреби в Opik, Langfuse або іншому зовнішньому колекторі. +- Запускайте `pnpm release:check` перед кожним тегованим релізом +- Релізні перевірки тепер запускаються в окремому ручному workflow: `OpenClaw Release Checks` -- `OpenClaw Release Checks` також запускає mock parity gate QA Lab, швидкий live-профіль Matrix і Telegram QA lane перед схваленням релізу. Live lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний паралельний інвентар Matrix transport, media і E2EE. -- Cross-OS перевірка встановлення й оновлення runtime є частиною публічних `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають багаторазовий workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` -- Цей поділ навмисний: тримайте справжній шлях npm-релізу коротким, детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються у власній lane, щоб вони не затримували й не блокували публікацію -- Релізні перевірки з секретами слід запускати через `Full Release Validation` або з workflow ref `main`/release, щоб логіка workflow і секрети залишалися контрольованими -- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо розв’язаний коміт доступний з гілки OpenClaw або релізного тегу -- `OpenClaw NPM Release` validation-only preflight також приймає поточний повний 40-символьний SHA коміту workflow branch без вимоги до запушеного тегу -- Цей шлях SHA призначений лише для перевірки й не може бути підвищений до справжньої публікації -- У режимі SHA workflow синтезує `v` лише для перевірки метаданих пакета; справжня публікація все ще потребує справжнього релізного тегу -- Обидва workflow залишають шлях справжньої публікації та просування на GitHub-hosted runners, тоді як немутаційний шлях перевірки може використовувати більші Linux runners Blacksmith +- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс швидкий + live Matrix profile і Telegram QA lane перед схваленням релізу. Live + lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з + `matrix_profile=all` і `matrix_shards=true`, коли потрібна повна інвентаризація Matrix + transport, media та E2EE паралельно. +- Cross-OS install і upgrade runtime validation є частиною публічних + `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають + reusable workflow + `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` +- Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким, + детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються у власній + lane, щоб не затримувати й не блокувати публікацію +- Релізні перевірки із секретами слід запускати через `Full Release +Validation` або з workflow ref `main`/release, щоб логіка workflow і + секрети залишалися контрольованими +- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо + резолвлений коміт доступний з гілки OpenClaw або релізного тегу +- Validation-only preflight `OpenClaw NPM Release` також приймає поточний + повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу +- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації +- У режимі SHA workflow синтезує `v` лише для + перевірки метаданих пакета; реальна публікація все одно вимагає справжнього релізного тегу +- Обидва workflows тримають реальний шлях публікації та promotion на GitHub-hosted + runners, тоді як немутаційний шлях валідації може використовувати більші + Blacksmith Linux runners - Цей workflow запускає `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` - використовуючи workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` -- npm release preflight більше не чекає на окрему lane релізних перевірок + з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` +- npm release preflight більше не чекає на окрему lane release checks - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` (або відповідний beta/correction тег) перед схваленням - Після npm publish запустіть `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну beta/correction версію), щоб перевірити шлях встановлення з опублікованого registry у свіжий тимчасовий prefix -- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`, щоб перевірити onboarding встановленого пакета, налаштування Telegram і справжній Telegram E2E проти опублікованого npm-пакета з використанням спільного leased pool облікових даних Telegram. Локальні одноразові запуски maintainer можуть опустити змінні Convex і передати три env credentials `OPENCLAW_QA_TELEGRAM_*` напряму. -- Maintainers можуть запускати ту саму післяпублікаційну перевірку з GitHub Actions через ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і не запускається під час кожного merge. + (або відповідну beta/correction версію), щоб перевірити шлях встановлення з опублікованого registry + у свіжому тимчасовому prefix +- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live` + щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E + проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram. + Локальні одноразові запуски maintainers можуть опускати змінні Convex і передавати три + env-облікові дані `OPENCLAW_QA_TELEGRAM_*` напряму. +- Maintainers можуть запускати ту саму post-publish перевірку з GitHub Actions через + ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і + не запускається під час кожного merge. - Автоматизація релізів maintainer тепер використовує preflight-then-promote: - - справжній npm publish має пройти успішний npm `preflight_run_id` - - справжній npm publish має бути запущений з тієї самої гілки `main` або `release/YYYY.M.D`, що й успішний preflight run - - stable npm releases за замовчуванням використовують `beta` - - stable npm publish може явно націлюватися на `latest` через workflow input - - token-based npm dist-tag mutation тепер живе в `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only publish - - публічний `macOS Release` є validation-only; коли тег існує лише на release branch, але workflow запускається з `main`, задайте `public_release_branch=release/YYYY.M.D` - - справжній private mac publish має пройти успішні private mac `preflight_run_id` і `validate_run_id` - - шляхи справжньої публікації просувають підготовлені артефакти, а не перебудовують їх знову -- Для stable correction releases на кшталт `YYYY.M.D-N` післяпублікаційний verifier також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`, щоб release corrections не могли непомітно залишити старіші global installs на базовому stable payload -- npm release preflight fail-closed, якщо tarball не містить і `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, щоб ми знову не відвантажили порожню браузерну панель керування -- Післяпублікаційна перевірка також перевіряє наявність опублікованих plugin entrypoints і метаданих пакета в установленому registry layout. Реліз, у якому відсутні plugin runtime payloads, провалює postpublish verifier і не може бути просунутий до `latest`. -- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до candidate update tarball, щоб installer e2e ловив випадкове роздування пакета до release publish path -- Якщо релізна робота зачепила планування CI, manifests timing plugin або extension test matrices, перегенеруйте й перегляньте planner-owned matrix outputs `plugin-prerelease-extension-shard` з `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не описували застарілий CI layout -- Готовність stable macOS release також охоплює updater surfaces: - - GitHub release має в підсумку містити запаковані `.zip`, `.dmg` і `.dSYM.zip` + - реальний npm publish має пройти успішний npm `preflight_run_id` + - реальний npm publish має бути запущений з тієї самої гілки `main` або + `release/YYYY.M.D`, що й успішний preflight run + - стабільні npm-релізи за замовчуванням спрямовуються на `beta` + - стабільний npm publish може явно націлюватися на `latest` через workflow input + - мутація npm dist-tag на основі токена тепер живе в + `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` + з міркувань безпеки, бо `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як + публічний репозиторій зберігає OIDC-only publish + - публічний `macOS Release` призначений лише для валідації; коли тег існує лише в + release branch, але workflow запускається з `main`, встановіть + `public_release_branch=release/YYYY.M.D` + - реальний приватний mac publish має пройти успішні приватні mac + `preflight_run_id` і `validate_run_id` + - реальні шляхи публікації просувають підготовлені артефакти замість того, щоб + перебудовувати їх знову +- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier + також перевіряє той самий шлях оновлення з тимчасовим prefix з `YYYY.M.D` до `YYYY.M.D-N`, + щоб release corrections не могли непомітно залишити старіші глобальні встановлення на + базовому stable payload +- npm release preflight fails closed, якщо tarball не містить одночасно + `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`, + щоб ми знову не відправили порожню browser dashboard +- Post-publish verification також перевіряє, що опубліковані plugin entrypoints і + метадані пакета присутні у встановленому registry layout. Реліз, який + постачає відсутні plugin runtime payloads, провалює postpublish verifier і + не може бути просунутий до `latest`. +- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до + candidate update tarball, тож installer e2e ловить випадкове роздування pack + до шляху release publish +- Якщо релізна робота торкалася планування CI, manifests таймінгів extension або + матриць тестів extension, регенеруйте й перегляньте outputs матриці + `plugin-prerelease-extension-shard`, якими володіє planner, з + `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не + описували застарілий CI layout +- Готовність stable macOS release також включає surfaces оновлювача: + - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip` - `appcast.xml` на `main` має вказувати на новий stable zip після publish - - запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor для цієї release version + - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed + URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor + для цієї релізної версії ## Релізні тестові бокси -`Full Release Validation` - це спосіб, яким оператори запускають усі передрелізні тести з однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте release branch, тег або повний SHA коміту як `ref`: +`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з +однієї точки входу. Запустіть його з довіреного workflow ref `main` і передайте release +branch, tag або full commit SHA як `ref`: ```bash gh workflow run full-release-validation.yml \ @@ -168,25 +252,35 @@ gh workflow run full-release-validation.yml \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N ``` -Workflow розв’язує target ref, запускає ручний `CI` з `target_ref=`, запускає `OpenClaw Release Checks` і опційно запускає standalone post-publish Telegram E2E, коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release Checks` розгалужується на install smoke, cross-OS release checks, live/E2E Docker release-path coverage, Package Acceptance з Telegram package QA, QA Lab parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли summary `Full Release Validation` показує `normal_ci` і `release_checks` як successful, а будь-який опційний дочірній `npm_telegram` є або successful, або навмисно skipped. Фінальний verifier summary містить таблиці slowest-job для кожного child run, щоб release manager міг бачити поточний critical path без завантаження logs. -Див. [Повну перевірку релізу](/uk/reference/full-release-validation) для повної матриці етапів, точних назв workflow jobs, відмінностей між stable і full profiles, артефактів і focused rerun handles. -Child workflows запускаються з довіреного ref, який запускає `Full Release Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на старішу release branch або tag. Окремого Full Release Validation workflow-ref input немає; вибирайте довірений harness, вибираючи workflow run ref. +Workflow резолвить target ref, запускає ручний `CI` з +`target_ref=`, запускає `OpenClaw Release Checks` і запускає +standalone package Telegram E2E, коли `release_profile=full` з +`rerun_group=all` або коли встановлено `npm_telegram_package_spec`. `OpenClaw Release +Checks` далі розгортається на install smoke, cross-OS release checks, live/E2E Docker +release-path coverage, Package Acceptance з Telegram package QA, QA Lab +parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли +summary `Full Release Validation` +показує `normal_ci` і `release_checks` як успішні. У режимі full/all +дочірній `npm_telegram` також має бути успішним; поза full/all його пропущено, +якщо не було надано опублікований `npm_telegram_package_spec`. Фінальний +verifier summary містить таблиці найповільніших jobs для кожного дочірнього run, щоб release +manager міг бачити поточний критичний шлях без завантаження logs. +Див. [Повна валідація релізу](/uk/reference/full-release-validation) для +повної stage matrix, точних назв workflow jobs, відмінностей stable versus full profile, +artifacts і handles для focused rerun. +Дочірні workflows запускаються з довіреного ref, який запускає `Full Release +Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на +старішу release branch або tag. Окремого input workflow-ref для Full Release Validation +немає; вибирайте довірений harness, вибираючи ref workflow run. Використовуйте `release_profile`, щоб вибрати ширину live/provider: - `minimum`: найшвидший release-critical OpenAI/core live і Docker path - `stable`: minimum плюс stable provider/backend coverage для release approval -- `full`: stable плюс широкий advisory provider/media coverage +- `full`: stable плюс broad advisory provider/media coverage -`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз визначити цільове -посилання як `release-package-under-test`, і повторно використовує цей артефакт як у Docker-перевірках -шляху релізу, так і в Package Acceptance. Це утримує всі -бокси, що працюють із пакетами, на тих самих байтах і уникає повторних збірок пакетів. -Крос-ОС інсталяційний smoke для OpenAI використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли -змінну репозиторію/організації задано, інакше `openai/gpt-5.5`, бо ця лінія -перевіряє встановлення пакета, onboarding, запуск Gateway і один живий хід агента, -а не бенчмарк найповільнішої стандартної моделі. Ширша жива матриця провайдерів -залишається місцем для покриття, специфічного для моделей. +`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз визначити цільове посилання як `release-package-under-test`, і повторно використовує цей artifact як у Docker-перевірках release-path, так і в Package Acceptance. Це утримує всі package-facing boxes на тих самих байтах і уникає повторних збірок package. +Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли встановлено змінну repo/org, інакше `openai/gpt-5.5`, оскільки ця lane перевіряє package install, onboarding, Gateway startup і один live agent turn, а не benchmark найповільнішої моделі за замовчуванням. Ширша матриця live provider лишається місцем для model-specific coverage. Використовуйте ці варіанти залежно від етапу релізу: @@ -212,45 +306,28 @@ gh workflow run full-release-validation.yml \ -f ref=release/YYYY.M.D \ -f provider=openai \ -f mode=both \ + -f release_profile=full \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N \ -f npm_telegram_package_spec=openclaw@YYYY.M.D-beta.N \ -f npm_telegram_provider_mode=mock-openai ``` -Не використовуйте повну парасольку як перший повторний запуск після сфокусованого виправлення. Якщо один бокс -падає, використовуйте невдалий дочірній workflow, job, Docker-лінію, профіль пакета, провайдера -моделі або QA-лінію для наступного доказу. Запускайте повну парасольку знову лише тоді, коли -виправлення змінило спільну оркестрацію релізу або зробило попередні докази з усіх боксів -застарілими. Фінальний верифікатор парасольки повторно перевіряє записані id запусків дочірніх workflow, -тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдалий -батьківський job `Verify full validation`. +Не використовуйте повний umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box завершується з помилкою, використовуйте failed child workflow, job, Docker lane, package profile, model provider або QA lane для наступного доказу. Запускайте повний umbrella знову лише тоді, коли виправлення змінило shared release orchestration або зробило попередні all-box evidence застарілими. Фінальний verifier umbrella повторно перевіряє записані child workflow run ids, тож після успішного повторного запуску child workflow перезапустіть лише failed parent job `Verify full validation`. -Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` — це справжній -запуск release-candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease` -запускає лише релізний дочірній plugin, `release-checks` запускає кожен релізний -бокс, а вужчі релізні групи — це `install-smoke`, `cross-os`, -`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`, коли -надано автономну пакетну Telegram-лінію. +Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` — це справжній release-candidate run, `ci` запускає лише normal CI child, `plugin-prerelease` запускає лише release-only plugin child, `release-checks` запускає кожен release box, а вужчі release groups — це `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`. Сфокусовані повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all runs із `release_profile=full` використовують package artifact із release-checks. ### Vitest -Бокс Vitest — це ручний дочірній workflow `CI`. Ручний CI навмисно -обходить змінене скоупування і примусово запускає звичайний граф тестів для release -candidate: Linux Node shards, bundled-plugin shards, channel contracts, сумісність із Node 22, -`check`, `check-additional`, build smoke, перевірки документації, Python -skills, Windows, macOS, Android і Control UI i18n. +Vitest box — це manual `CI` child workflow. Manual CI навмисно обходить changed scoping і примусово запускає normal test graph для release candidate: Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS, Android і Control UI i18n. -Використовуйте цей бокс, щоб відповісти на запитання «чи дерево джерел пройшло повний звичайний набір тестів?» -Це не те саме, що продуктова валідація шляху релізу. Докази, які слід зберігати: +Використовуйте цей box, щоб відповісти: «чи пройшло source tree повний normal test suite?» Це не те саме, що release-path product validation. Evidence, які слід зберігати: -- підсумок `Full Release Validation`, що показує URL запущеного `CI` -- зелений запуск `CI` на точному цільовому SHA -- назви невдалих або повільних shard із CI jobs під час розслідування регресій -- артефакти таймінгів Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли - запуск потребує аналізу продуктивності +- summary `Full Release Validation`, що показує dispatched `CI` run URL +- зелений `CI` run на точному target SHA +- назви failed або slow shards із CI jobs під час розслідування regressions +- Vitest timing artifacts, як-от `.artifacts/vitest-shard-timings.json`, коли run потребує performance analysis -Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але -не потрібні Docker, QA Lab, live, cross-OS або пакетні бокси: +Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal CI, але не Docker, QA Lab, live, cross-OS або package boxes: ```bash gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D @@ -258,108 +335,61 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D ### Docker -Бокс Docker живе в `OpenClaw Release Checks` через -`openclaw-live-and-e2e-checks-reusable.yml`, плюс workflow `install-smoke` -у режимі релізу. Він валідовує release candidate через упаковані -Docker-середовища, а не лише через тести на рівні джерел. +Docker box знаходиться в `OpenClaw Release Checks` через `openclaw-live-and-e2e-checks-reusable.yml`, а також release-mode workflow `install-smoke`. Він перевіряє release candidate через packaged Docker environments, а не лише source-level tests. -Покриття релізного Docker включає: +Release Docker coverage включає: -- повний install smoke з увімкненим повільним Bun global install smoke -- підготовку/повторне використання smoke-образу кореневого Dockerfile за цільовим SHA, з QR, - root/gateway і installer/Bun smoke jobs, що виконуються як окремі install-smoke - shards -- репозиторні E2E-лінії -- Docker-частини шляху релізу: `core`, `package-update-openai`, +- full install smoke з увімкненим slow Bun global install smoke +- підготовку/повторне використання root Dockerfile smoke image за target SHA, де QR, root/Gateway і installer/Bun smoke jobs запускаються як окремі install-smoke shards +- repository E2E lanes +- release-path Docker chunks: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a`, `plugins-runtime-install-b`, `plugins-runtime-install-c`, `plugins-runtime-install-d`, `plugins-runtime-install-e`, `plugins-runtime-install-f`, `plugins-runtime-install-g` і `plugins-runtime-install-h` -- покриття OpenWebUI всередині частини `plugins-runtime-services`, коли його запитано -- розділені лінії встановлення/видалення bundled plugin +- OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли це запитано +- розділені bundled plugin install/uninstall lanes `bundled-plugin-install-uninstall-0` до `bundled-plugin-install-uninstall-23` -- live/E2E-набори провайдерів і Docker-покриття живих моделей, коли релізні перевірки - включають live-набори +- live/E2E provider suites і Docker live model coverage, коли release checks + включають live suites -Використовуйте Docker-артефакти перед повторним запуском. Планувальник шляху релізу завантажує -`.artifacts/docker-tests/` з логами ліній, `summary.json`, `failures.json`, -таймінгами фаз, JSON плану планувальника і командами повторного запуску. Для сфокусованого відновлення -використовуйте `docker_lanes=` у багаторазовому live/E2E workflow замість -повторного запуску всіх релізних частин. Згенеровані команди повторного запуску містять попередні -`package_artifact_run_id` і підготовлені Docker image inputs, коли вони доступні, щоб -невдала лінія могла повторно використати той самий tarball і GHCR-образи. +Використовуйте Docker artifacts перед повторним запуском. Release-path scheduler завантажує `.artifacts/docker-tests/` із lane logs, `summary.json`, `failures.json`, phase timings, scheduler plan JSON і rerun commands. Для сфокусованого відновлення використовуйте `docker_lanes=` у reusable live/E2E workflow замість повторного запуску всіх release chunks. Згенеровані rerun commands містять попередній `package_artifact_run_id` і prepared Docker image inputs, коли доступні, тому failed lane може повторно використати той самий tarball і GHCR images. ### QA Lab -Бокс QA Lab також є частиною `OpenClaw Release Checks`. Це релізний gate -агентної поведінки та рівня каналів, окремий від Vitest і механіки Docker -пакетів. +QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic behavior і channel-level release gate, окремий від Vitest і Docker package mechanics. -Покриття релізного QA Lab включає: +Release QA Lab coverage включає: -- gate mock parity, що порівнює кандидатну лінію OpenAI з baseline Opus 4.6 - за допомогою agentic parity pack -- швидкий live Matrix QA profile із використанням середовища `qa-live-shared` -- live Telegram QA lane із lease облікових даних Convex CI -- `pnpm qa:otel:smoke`, коли релізна телеметрія потребує явного локального доказу +- mock parity gate, що порівнює candidate lane OpenAI з baseline Opus 4.6 за допомогою agentic parity pack +- fast live Matrix QA profile з використанням environment `qa-live-shared` +- live Telegram QA lane з використанням Convex CI credential leases +- `pnpm qa:otel:smoke`, коли release telemetry потребує explicit local proof -Використовуйте цей бокс, щоб відповісти на запитання «чи реліз поводиться коректно в QA-сценаріях і -живих потоках каналів?» Зберігайте URL артефактів для ліній parity, Matrix і Telegram -під час схвалення релізу. Повне покриття Matrix залишається доступним як -ручний sharded QA-Lab запуск, а не стандартна критична для релізу лінія. +Використовуйте цей box, щоб відповісти: «чи реліз поводиться правильно в QA scenarios і live channel flows?» Зберігайте artifact URLs для parity, Matrix і Telegram lanes під час схвалення релізу. Full Matrix coverage лишається доступним як manual sharded QA-Lab run, а не default release-critical lane. -### Пакет +### Package -Бокс Package — це gate інстальованого продукту. Його підтримують -`Package Acceptance` і резолвер -`scripts/resolve-openclaw-package-candidate.mjs`. Резолвер нормалізує -кандидата в tarball `package-under-test`, який споживає Docker E2E, валідовує -інвентар пакета, записує версію пакета й SHA-256, і тримає -посилання harness workflow окремо від посилання джерела пакета. +Package box — це installable-product gate. Він підтримується `Package Acceptance` і resolver `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує candidate у tarball `package-under-test`, який споживає Docker E2E, перевіряє package inventory, записує package version і SHA-256, а також тримає workflow harness ref окремо від package source ref. -Підтримувані джерела кандидатів: +Підтримувані candidate sources: -- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна release - версія OpenClaw -- `source=ref`: запакувати довірену гілку `package_ref`, тег або повний commit SHA - з вибраним harness `workflow_ref` -- `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256` -- `source=artifact`: повторно використати `.tgz`, завантажений іншим запуском GitHub Actions +- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release version +- `source=ref`: пакує довірені `package_ref` branch, tag або full commit SHA з вибраним harness `workflow_ref` +- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256` +- `source=artifact`: повторно використовує `.tgz`, завантажений іншим GitHub Actions run -`OpenClaw Release Checks` запускає Package Acceptance із `source=artifact`, підготовленим -артефактом релізного пакета, `suite_profile=custom`, -`docker_lanes=doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update`, -`published_upgrade_survivor_baselines=release-history`, -`published_upgrade_survivor_scenarios=reported-issues` і -`telegram_mode=mock-openai`. Package Acceptance утримує перевірки міграції, оновлення, очищення -застарілих залежностей plugin, offline plugin fixtures, оновлення plugin і Telegram -package QA на тому самому розв’язаному tarball. Це GitHub-native -заміна для більшості покриття package/update, яке раніше вимагало -Parallels. Крос-ОС релізні перевірки все ще важливі для OS-специфічного onboarding, -інсталятора та поведінки платформи, але product validation package/update має -віддавати перевагу Package Acceptance. +`OpenClaw Release Checks` запускає Package Acceptance із `source=artifact`, підготовленим release package artifact, `suite_profile=custom`, `docker_lanes=doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Package Acceptance тримає migration, update, stale plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram package QA проти того самого resolved tarball. Це GitHub-native replacement для більшої частини package/update coverage, яка раніше потребувала Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding, installer і platform behavior, але package/update product validation має надавати перевагу Package Acceptance. -Канонічний checklist для валідації оновлень і plugins: -[Тестування оновлень і plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли -вирішуєте, яка локальна, Docker, Package Acceptance або release-check лінія доводить -встановлення/оновлення plugin, doctor cleanup або зміну міграції published-package. +Канонічний checklist для update і plugin validation — це +[Тестування оновлень і плагінів](/uk/help/testing-updates-plugins). Використовуйте його, коли вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить зміну plugin install/update, doctor cleanup або published-package migration. -Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до -`2026.4.25` включно можуть використовувати шлях сумісності для прогалин у метаданих, уже опублікованих -у npm: приватні записи QA inventory, відсутні в tarball, відсутній -`gateway install --wrapper`, відсутні patch-файли у git -fixture, отриманій із tarball, відсутній збережений `update.channel`, legacy plugin install-record -locations, відсутня персистентність marketplace install-record і міграція config metadata -під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати -про локальні файли штампів build metadata, які вже були доставлені. Пізніші пакети -мають задовольняти сучасні package contracts; ті самі прогалини провалюють релізну -валідацію. +Legacy package-acceptance leniency навмисно обмежено в часі. Packages до `2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих у npm: private QA inventory entries, яких бракує в tarball; відсутній `gateway install --wrapper`; відсутні patch files у tarball-derived git fixture; відсутній persisted `update.channel`; legacy plugin install-record locations; відсутня marketplace install-record persistence; і config metadata migration під час `plugins update`. Published package `2026.4.26` може попереджати про local build metadata stamp files, які вже були shipped. Пізніші packages мають відповідати modern package contracts; ті самі gaps провалюють release validation. -Використовуйте ширші профілі Package Acceptance, коли релізне питання стосується -фактичного інстальованого пакета: +Використовуйте ширші Package Acceptance profiles, коли release question стосується фактичного installable package: ```bash gh workflow run package-acceptance.yml \ @@ -371,87 +401,83 @@ gh workflow run package-acceptance.yml \ -f published_upgrade_survivor_baseline=openclaw@2026.4.26 ``` -Поширені профілі пакетів: +Поширені package profiles: -- `smoke`: швидкі лінії встановлення пакета/channel/agent, gateway network і config - reload -- `package`: контракти install/update/plugin package без live ClawHub; це стандарт - release-check -- `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web +- `smoke`: швидкі package install/channel/agent, Gateway network і config reload lanes +- `package`: install/update/plugin package contracts без live ClawHub; це release-check + default +- `product`: `package` плюс MCP channels, Cron/subagent cleanup, OpenAI web search і OpenWebUI -- `full`: Docker-частини шляху релізу з OpenWebUI -- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків +- `full`: Docker release-path chunks з OpenWebUI +- `custom`: точний список `docker_lanes` для сфокусованих reruns -Для Telegram-доказу package-candidate увімкніть `telegram_mode=mock-openai` або -`telegram_mode=live-frontier` у Package Acceptance. Workflow передає -розв’язаний tarball `package-under-test` у Telegram-лінію; автономний -Telegram workflow все ще приймає опубліковану npm spec для post-publish перевірок. +Для package-candidate Telegram proof увімкніть `telegram_mode=mock-openai` або `telegram_mode=live-frontier` у Package Acceptance. Workflow передає resolved tarball `package-under-test` у Telegram lane; standalone Telegram workflow і далі приймає published npm spec для post-publish checks. ## Вхідні дані NPM workflow -`OpenClaw NPM Release` приймає ці контрольовані оператором inputs: +`OpenClaw NPM Release` приймає такі operator-controlled inputs: -- `tag`: обов’язковий релізний тег, такий як `v2026.4.2`, `v2026.4.2-1` або +- `tag`: обов’язковий release tag, наприклад `v2026.4.2`, `v2026.4.2-1` або `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний - повний 40-символьний SHA коміту workflow-branch для validation-only preflight -- `preflight_only`: `true` для лише валідації/build/package, `false` для - справжнього шляху публікації -- `preflight_run_id`: обов’язковий на справжньому шляху публікації, щоб workflow повторно використовував - підготовлений tarball з успішного preflight run -- `npm_dist_tag`: цільовий npm-тег для шляху публікації; стандартно `beta` + full 40-character workflow-branch commit SHA для validation-only preflight +- `preflight_only`: `true` для лише validation/build/package, `false` для + real publish path +- `preflight_run_id`: обов’язковий у real publish path, щоб workflow повторно використовував + prepared tarball з успішного preflight run +- `npm_dist_tag`: npm target tag для publish path; за замовчуванням `beta` -`OpenClaw Release Checks` приймає ці контрольовані оператором inputs: +`OpenClaw Release Checks` приймає такі operator-controlled inputs: -- `ref`: гілка, тег або повний commit SHA для валідації. Перевірки із секретами - вимагають, щоб розв’язаний коміт був досяжний із гілки OpenClaw або - релізного тегу. +- `ref`: branch, tag або full commit SHA для перевірки. Secret-bearing checks + вимагають, щоб resolved commit був доступний з OpenClaw branch або + release tag. Правила: - Stable і correction tags можуть публікуватися або в `beta`, або в `latest` - Beta prerelease tags можуть публікуватися лише в `beta` -- Для `OpenClaw NPM Release` введення повного commit SHA дозволене лише коли +- Для `OpenClaw NPM Release` full commit SHA input дозволений лише коли `preflight_only=true` - `OpenClaw Release Checks` і `Full Release Validation` завжди - лише для валідації -- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час preflight; - workflow перевіряє ці метадані перед продовженням публікації + validation-only +- Real publish path має використовувати той самий `npm_dist_tag`, що використовувався під час preflight; + workflow перевіряє ці metadata перед продовженням publish ## Послідовність стабільного npm-релізу -Під час підготовки стабільного npm-релізу: +Під час створення stable npm release: 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` - - До появи тегу можна використати поточний повний SHA коміту гілки робочого процесу - для валідаційного пробного запуску робочого процесу попередньої перевірки -2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише - тоді, коли ви навмисно хочете опублікувати стабільну версію напряму + - До створення тегу можна використати поточний повний SHA коміту гілки workflow + для сухого запуску лише валідації workflow передперевірки +2. Виберіть `npm_dist_tag=beta` для звичайного потоку спочатку beta або `latest` лише + тоді, коли ви навмисно хочете виконати безпосередню стабільну публікацію 3. Запустіть `Full Release Validation` на гілці релізу, тегу релізу або повному - SHA коміту, коли потрібні звичайний CI, а також live prompt cache, Docker, QA Lab, - Matrix і покриття Telegram з одного ручного робочого процесу + SHA коміту, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab, + Matrix і покриття Telegram з одного ручного workflow 4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть - ручний робочий процес `CI` на ref релізу + ручний workflow `CI` на посиланні релізу 5. Збережіть успішний `preflight_run_id` -6. Запустіть `OpenClaw NPM Release` ще раз із `preflight_only=false`, тим самим +6. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id` -7. Якщо реліз потрапив у `beta`, використайте приватний робочий процес +7. Якщо реліз потрапив на `beta`, використайте приватний workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, - щоб підвищити цю стабільну версію з `beta` до `latest` -8. Якщо реліз навмисно опубліковано напряму в `latest`, а `beta` - має негайно вказувати на ту саму стабільну збірку, використайте той самий приватний - робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій - самовідновлювальній синхронізації перемістити `beta` пізніше + щоб просунути цю стабільну версію з `beta` до `latest` +8. Якщо реліз навмисно опубліковано безпосередньо до `latest`, а `beta` + має негайно слідувати за тією самою стабільною збіркою, використайте той самий приватний + workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій + самовідновлюваній синхронізації перемістити `beta` пізніше -Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, оскільки для неї все ще -потрібен `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC. +Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, оскільки вона все ще +потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC. -Це робить і шлях прямої публікації, і шлях просування beta-first +Це робить і шлях прямої публікації, і шлях просування спочатку beta задокументованими та видимими для оператора. -Якщо супроводжувачу потрібно вдатися до локальної автентифікації npm, запускайте будь-які команди 1Password -CLI (`op`) лише в окремому сеансі tmux. Не викликайте `op` -напряму з основної оболонки агента; утримання його всередині tmux робить підказки, -сповіщення та обробку OTP спостережуваними й запобігає повторним сповіщенням хоста. +Якщо maintainer має повернутися до локальної npm-автентифікації, виконуйте будь-які команди +1Password CLI (`op`) лише всередині окремої сесії tmux. Не викликайте `op` +безпосередньо з основної оболонки агента; утримання його всередині tmux робить підказки, +сповіщення й обробку OTP видимими та запобігає повторним сповіщенням хоста. ## Публічні посилання @@ -465,10 +491,10 @@ CLI (`op`) лише в окремому сеансі tmux. Не викликай - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) -Супроводжувачі використовують приватну документацію релізів у +Maintainers використовують приватну документацію релізів у [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) -як фактичний регламент запуску. +для фактичного runbook. -## Пов’язане +## Пов'язане - [Канали релізів](/uk/install/development-channels) diff --git a/docs/uk/reference/full-release-validation.md b/docs/uk/reference/full-release-validation.md index 1ed404f00..3cb20637b 100644 --- a/docs/uk/reference/full-release-validation.md +++ b/docs/uk/reference/full-release-validation.md @@ -1,24 +1,25 @@ --- read_when: - - Запуск або повторний запуск повної валідації релізу - - Порівняння стабільного та повного профілів валідації випуску - - Налагодження збоїв на етапі валідації релізу -summary: Етапи повної валідації релізу, дочірні робочі процеси, профілі релізів, дескриптори повторного запуску та докази + - Запуск або повторний запуск повної перевірки релізу + - Порівняння стабільного та повного профілів перевірки випуску + - Налагодження збоїв на етапі перевірки релізу +summary: Етапи повної валідації релізу, дочірні робочі процеси, профілі релізу, ідентифікатори повторних запусків і докази title: Повна перевірка релізу x-i18n: - generated_at: "2026-05-01T20:41:10Z" + generated_at: "2026-05-01T23:10:06Z" model: gpt-5.5 provider: openai - source_hash: 032cf35578bc56187cdf3776dada58ccbde9a24183896bc71c3a782e85fc834f + source_hash: feb4edec850fb97405575c869547b4851bc773507321690670553e6faafc8b0b source_path: reference/full-release-validation.md workflow: 16 --- -`Full Release Validation` — це парасольковий релізний процес. Це єдина ручна -точка входу для передрелізного підтвердження, але більшість роботи відбувається в дочірніх workflows, щоб -невдалий блок можна було перезапустити без перезапуску всього релізу. +`Full Release Validation` — це парасолька релізу. Це єдина ручна +точка входу для передрелізного підтвердження, але більшість роботи виконується +в дочірніх workflow, щоб невдалий бокс можна було перезапустити без повторного +запуску всього релізу. -Запускайте його з довіреного workflow ref, зазвичай `main`, і передавайте релізну гілку, +Запускайте її з довіреного ref workflow, зазвичай `main`, і передайте релізну гілку, тег або повний SHA коміту як `ref`: ```bash @@ -30,129 +31,135 @@ gh workflow run full-release-validation.yml \ -f release_profile=stable ``` -Дочірні workflows використовують довірений workflow ref для harness і вхідний -`ref` для кандидата, що тестується. Це забезпечує доступність нової логіки валідації -під час перевірки старішої релізної гілки або тега. +Дочірні workflow використовують довірений ref workflow для harness і вхідний +`ref` для кандидата, що тестується. Це зберігає нову логіку валідації доступною +під час валідації старішої релізної гілки або тегу. -## Етапи верхнього рівня +## Верхньорівневі етапи -| Етап | Подробиці | -| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Розв’язання цілі | **Job:** `Resolve target ref`
**Дочірній workflow:** немає
**Підтверджує:** розв’язує релізну гілку, тег або повний SHA коміту та записує вибрані вхідні параметри.
**Перезапуск:** перезапустіть парасольковий workflow, якщо це не вдається. | -| Vitest і звичайний CI | **Job:** `Run normal full CI`
**Дочірній workflow:** `CI`
**Підтверджує:** ручний повний граф CI для цільового ref, включно з Linux Node lanes, сегментами bundled Plugin, контрактами каналів, сумісністю Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n і Android через парасольковий workflow.
**Перезапуск:** `rerun_group=ci`. | -| Передреліз Plugin | **Job:** `Run plugin prerelease validation`
**Дочірній workflow:** `Plugin Prerelease`
**Підтверджує:** релізні статичні перевірки Plugin, agentic покриття Plugin, повні пакетні сегменти extension і Docker lanes передрелізу Plugin.
**Перезапуск:** `rerun_group=plugin-prerelease`. | -| Релізні перевірки | **Job:** `Run release/live/Docker/QA validation`
**Дочірній workflow:** `OpenClaw Release Checks`
**Підтверджує:** install smoke, перевірки пакетів між ОС, live/E2E набори, частини Docker release-path, Package Acceptance, QA Lab parity, live Matrix і live Telegram.
**Перезапуск:** `rerun_group=release-checks` або вужчий handle release-checks. | -| Telegram після публікації | **Job:** `Run post-publish Telegram E2E`
**Дочірній workflow:** `NPM Telegram Beta E2E`
**Підтверджує:** необов’язкове підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.
**Перезапуск:** `rerun_group=npm-telegram`. | -| Верифікатор парасолькового workflow | **Job:** `Verify full validation`
**Дочірній workflow:** немає
**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших jobs із дочірніх workflows.
**Перезапуск:** перезапустіть лише цей job після успішного перезапуску невдалого дочірнього workflow. | +| Етап | Деталі | +| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Визначення цілі | **Job:** `Resolve target ref`
**Дочірній workflow:** немає
**Підтверджує:** визначає релізну гілку, тег або повний SHA коміту та записує вибрані вхідні параметри.
**Перезапуск:** перезапустіть парасольку, якщо це завершиться невдачею. | +| Vitest і звичайний CI | **Job:** `Run normal full CI`
**Дочірній workflow:** `CI`
**Підтверджує:** ручний повний граф CI для цільового ref, включно з Linux Node lanes, шардами вбудованих Plugin, контрактами каналів, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n та Android через парасольку.
**Перезапуск:** `rerun_group=ci`. | +| Передреліз Plugin | **Job:** `Run plugin prerelease validation`
**Дочірній workflow:** `Plugin Prerelease`
**Підтверджує:** релізні статичні перевірки Plugin, агентне покриття Plugin, повні batch-шарди extensions і Docker lanes передрелізу Plugin.
**Перезапуск:** `rerun_group=plugin-prerelease`. | +| Релізні перевірки | **Job:** `Run release/live/Docker/QA validation`
**Дочірній workflow:** `OpenClaw Release Checks`
**Підтверджує:** install smoke, cross-OS package checks, live/E2E suites, chunks релізного шляху Docker, Package Acceptance, паритет QA Lab, live Matrix і live Telegram.
**Перезапуск:** `rerun_group=release-checks` або вужчий handle release-checks. | +| Пакет Telegram | **Job:** `Run package Telegram E2E`
**Дочірній workflow:** `NPM Telegram Beta E2E`
**Підтверджує:** підтвердження пакета Telegram на основі артефакта для `rerun_group=all` з `release_profile=full`, або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.
**Перезапуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. | +| Верифікатор парасольки | **Job:** `Verify full validation`
**Дочірній workflow:** немає
**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших job з дочірніх workflow.
**Перезапуск:** після успішного перезапуску невдалого дочірнього workflow перезапустіть лише цей job. | -Для `ref=main` і `rerun_group=all` новіший парасольковий workflow замінює старіший. -Коли батьківський workflow скасовано, його монітор скасовує будь-який дочірній workflow, який він уже -запустив. Запуски валідації релізних гілок і тегів за замовчуванням не скасовують один одного. +Для `ref=main` і `rerun_group=all` новіша парасолька замінює старішу. +Коли батьківський запуск скасовано, його монітор скасовує будь-який дочірній +workflow, який він уже відправив. Запуски валідації релізної гілки й тегу +за замовчуванням не скасовують один одного. ## Етапи релізних перевірок -`OpenClaw Release Checks` — найбільший дочірній workflow. Він один раз розв’язує ціль -і готує спільний артефакт `release-package-under-test`, коли він потрібен етапам, -пов’язаним із пакетами або Docker. +`OpenClaw Release Checks` — найбільший дочірній workflow. Він один раз визначає +ціль і готує спільний артефакт `release-package-under-test`, коли він потрібен +етапам, що працюють із пакетами або Docker. -| Етап | Подробиці | -| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Релізна ціль | **Job:** `Resolve target ref`
**Базовий workflow:** немає
**Тести:** вибраний ref, необов’язковий очікуваний SHA, profile, rerun group і сфокусований фільтр live suite.
**Перезапуск:** `rerun_group=release-checks`. | -| Артефакт пакета | **Job:** `Prepare release package artifact`
**Базовий workflow:** немає
**Тести:** пакує або розв’язує один кандидатський tarball і завантажує `release-package-under-test` для downstream перевірок, пов’язаних із пакетами.
**Перезапуск:** відповідна package, cross-OS або live/E2E group. | -| Install smoke | **Job:** `Run install smoke`
**Базовий workflow:** `Install Smoke`
**Тести:** повний шлях інсталяції з повторним використанням root Dockerfile smoke image, встановлення QR package, root і Gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke і швидкий E2E встановлення/видалення bundled Plugin.
**Перезапуск:** `rerun_group=install-smoke`. | -| Cross-OS | **Job:** `cross_os_release_checks`
**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`
**Тести:** fresh і upgrade lanes на Linux, Windows і macOS для вибраних provider і mode, з використанням кандидатського tarball плюс baseline package.
**Перезапуск:** `rerun_group=cross-os`. | -| Repo і live E2E | **Job:** `Run repo/live E2E validation`
**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** repository E2E, live cache, OpenAI websocket streaming, native live provider і сегменти Plugin, а також Docker-backed live model/backend/Gateway harnesses, вибрані через `release_profile`.
**Перезапуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. | -| Docker release path | **Job:** `Run Docker release-path validation`
**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** частини release-path Docker зі спільним артефактом пакета.
**Перезапуск:** `rerun_group=live-e2e`. | -| Package Acceptance | **Job:** `Run package acceptance`
**Базовий workflow:** `Package Acceptance`
**Тести:** offline fixtures пакетів Plugin, оновлення Plugin і mock-OpenAI Telegram package acceptance для того самого tarball.
**Перезапуск:** `rerun_group=package`. | -| QA parity | **Job:** `Run QA Lab parity lane` і `Run QA Lab parity report`
**Базовий workflow:** прямі jobs
**Тести:** candidate і baseline agentic parity packs, а потім parity report.
**Перезапуск:** `rerun_group=qa-parity` або `rerun_group=qa`. | -| QA live Matrix | **Job:** `Run QA Lab live Matrix lane`
**Базовий workflow:** прямий job
**Тести:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.
**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`. | -| QA live Telegram | **Job:** `Run QA Lab live Telegram lane`
**Базовий workflow:** прямий job
**Тести:** live Telegram QA з leases облікових даних Convex CI.
**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`. | -| Релізний верифікатор | **Job:** `Verify release checks`
**Базовий workflow:** немає
**Тести:** обов’язкові release-check jobs для вибраної rerun group.
**Перезапуск:** перезапустіть після успішного проходження сфокусованих дочірніх jobs. | +| Етап | Деталі | +| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Ціль релізу | **Job:** `Resolve target ref`
**Базовий workflow:** немає
**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група перезапуску та сфокусований фільтр live suite.
**Перезапуск:** `rerun_group=release-checks`. | +| Артефакт пакета | **Job:** `Prepare release package artifact`
**Базовий workflow:** немає
**Тести:** пакує або визначає один tarball кандидата та завантажує `release-package-under-test` для подальших перевірок, що працюють із пакетами.
**Перезапуск:** відповідна група package, cross-OS або live/E2E. | +| Install smoke | **Job:** `Run install smoke`
**Базовий workflow:** `Install Smoke`
**Тести:** повний шлях установлення з повторним використанням smoke-образу root Dockerfile, встановлення QR-пакета, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke та швидкий E2E install/uninstall вбудованого Plugin.
**Перезапуск:** `rerun_group=install-smoke`. | +| Cross-OS | **Job:** `cross_os_release_checks`
**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`
**Тести:** fresh і upgrade lanes у Linux, Windows і macOS для вибраного провайдера та режиму, з використанням tarball кандидата плюс baseline-пакета.
**Перезапуск:** `rerun_group=cross-os`. | +| Repo і live E2E | **Job:** `Run repo/live E2E validation`
**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** repository E2E, live cache, OpenAI websocket streaming, native live provider і шарди Plugin, а також Docker-backed live model/backend/gateway harnesses, вибрані `release_profile`.
**Перезапуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. | +| Релізний шлях Docker | **Job:** `Run Docker release-path validation`
**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** chunks релізного шляху Docker проти спільного артефакта пакета.
**Перезапуск:** `rerun_group=live-e2e`. | +| Package Acceptance | **Job:** `Run package acceptance`
**Базовий workflow:** `Package Acceptance`
**Тести:** офлайн fixtures пакетів Plugin, оновлення Plugin і mock-OpenAI Telegram package acceptance проти того самого tarball.
**Перезапуск:** `rerun_group=package`. | +| QA parity | **Job:** `Run QA Lab parity lane` і `Run QA Lab parity report`
**Базовий workflow:** прямі jobs
**Тести:** кандидат і baseline agentic parity packs, потім parity report.
**Перезапуск:** `rerun_group=qa-parity` або `rerun_group=qa`. | +| QA live Matrix | **Job:** `Run QA Lab live Matrix lane`
**Базовий workflow:** прямий job
**Тести:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.
**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`. | +| QA live Telegram | **Job:** `Run QA Lab live Telegram lane`
**Базовий workflow:** прямий job
**Тести:** live Telegram QA з leases облікових даних Convex CI.
**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`. | +| Верифікатор релізу | **Job:** `Verify release checks`
**Базовий workflow:** немає
**Тести:** обов’язкові jobs release-check для вибраної групи перезапуску.
**Перезапуск:** перезапустіть після успішного проходження сфокусованих дочірніх jobs. | -## Частини Docker release-path +## Chunks релізного шляху Docker -Етап Docker release-path запускає ці частини, коли `live_suite_filter` порожній: +Етап релізного шляху Docker запускає ці chunks, коли `live_suite_filter` +порожній: -| Частина | Покриття | -| --------------------------------------------------------------- | ----------------------------------------------------------------------- | -| `core` | Core Docker release-path smoke lanes. | -| `package-update-openai` | Поведінка встановлення й оновлення пакета OpenAI. | -| `package-update-anthropic` | Поведінка встановлення й оновлення пакета Anthropic. | -| `package-update-core` | Провайдер-нейтральна поведінка пакета й оновлення. | -| `plugins-runtime-plugins` | Plugin runtime lanes, які перевіряють поведінку Plugin. | -| `plugins-runtime-services` | Service-backed Plugin runtime lanes; включає OpenWebUI, коли запитано. | -| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Пакети встановлення/runtime Plugin, розділені для паралельної релізної валідації. | +| Chunk | Покриття | +| --------------------------------------------------------------- | ------------------------------------------------------------------------- | +| `core` | Smoke lanes релізного шляху Core Docker. | +| `package-update-openai` | Поведінка встановлення й оновлення пакета OpenAI. | +| `package-update-anthropic` | Поведінка встановлення й оновлення пакета Anthropic. | +| `package-update-core` | Провайдер-нейтральна поведінка пакета й оновлення. | +| `plugins-runtime-plugins` | Runtime lanes Plugin, які перевіряють поведінку Plugin. | +| `plugins-runtime-services` | Runtime lanes Plugin на основі сервісів; включає OpenWebUI, коли запитано. | +| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Batch-перевірки встановлення/runtime Plugin, розділені для паралельної релізної валідації. | -Використовуйте цільовий `docker_lanes=` у reusable live/E2E workflow, коли -не пройшов лише один Docker lane. Релізні артефакти містять per-lane команди перезапуску -з артефактом пакета та вхідними параметрами повторного використання образу, коли вони доступні. +Використовуйте цільові `docker_lanes=` у reusable live/E2E workflow, +коли не пройшла лише одна Docker lane. Релізні артефакти містять команди +перезапуску для кожної lane з artifact пакета та вхідними параметрами повторного +використання образу, коли вони доступні. ## Релізні профілі -`release_profile` керує лише шириною live/provider у межах релізних перевірок. Він -не прибирає звичайний повний CI, Plugin Prerelease, install smoke, package -acceptance, QA Lab або частини Docker release-path. +`release_profile` переважно керує шириною live/provider усередині релізних перевірок. +Він не прибирає normal full CI, Plugin Prerelease, install smoke, package +acceptance, QA Lab або chunks релізного шляху Docker. `full` також змушує +парасольку запускати package Telegram E2E проти артефакта релізного пакета, +коли `rerun_group=all`, щоб повний pre-publish кандидат не пропустив мовчки +цю lane пакета Telegram. -| Профіль | Призначення | Включене покриття live/provider | -| -------- | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `minimum` | Найшвидший критично важливий релізний smoke. | Live-шлях OpenAI/core, live-моделі Docker для OpenAI, ядро нативного gateway, нативний профіль OpenAI gateway, нативний OpenAI plugin і Docker live gateway OpenAI. | -| `stable` | Стандартний профіль затвердження релізу. | `minimum` плюс Anthropic, Google, MiniMax, backend, нативний live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і smoke-шард OpenCode Go. | -| `full` | Широкий дорадчий огляд. | `stable` плюс дорадчі провайдери, live-шарди plugin і live-шарди медіа. | +| Профіль | Призначення | Включене покриття live/provider | +| -------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `minimum` | Найшвидший критичний для релізу smoke. | OpenAI/core live-шлях, Docker live-моделі для OpenAI, нативний core Gateway, нативний профіль OpenAI Gateway, нативний OpenAI Plugin і Docker live Gateway OpenAI. | +| `stable` | Стандартний профіль схвалення релізу. | `minimum` плюс Anthropic, Google, MiniMax, backend, нативний live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і smoke-шард OpenCode Go. | +| `full` | Широкий advisory-перегляд. | `stable` плюс advisory-провайдери, live-шарди Plugin і медіа live-шарди. | ## Доповнення лише для full -Ці набори пропускаються `stable` і включаються до `full`: +Ці набори пропускаються в `stable` і включаються в `full`: -| Область | Покриття лише для full | -| -------------------------------- | ------------------------------------------------------------------------------ | -| Docker live models | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks. | -| Docker live gateway | Дорадчий шард для DeepSeek, Fireworks, OpenCode Go, OpenRouter, xAI і Z.ai. | -| Native gateway provider profiles | Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai. | -| Native plugin live shards | Plugins A-K, L-N, O-Z other, Moonshot і xAI. | -| Native media live shards | Audio, Google music, MiniMax music і video groups A-D. | +| Область | Покриття лише для full | +| ------------------------------- | ---------------------------------------------------------------------------- | +| Docker live-моделі | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks. | +| Docker live Gateway | Advisory-шард для DeepSeek, Fireworks, OpenCode Go, OpenRouter, xAI і Z.ai. | +| Нативні профілі провайдерів Gateway | Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai. | +| Нативні live-шарди Plugin | Plugins A-K, L-N, O-Z other, Moonshot і xAI. | +| Нативні медіа live-шарди | Аудіо, музика Google, музика MiniMax і відеогрупи A-D. | `stable` включає `native-live-src-gateway-profiles-opencode-go-smoke`; `full` -використовує ширші шарди моделей OpenCode Go натомість. +натомість використовує ширші шарди моделей OpenCode Go. -## Сфокусовані повторні запуски +## Фокусовані повторні запуски Використовуйте `rerun_group`, щоб не повторювати непов’язані релізні бокси: -| Дескриптор | Обсяг | -| ------------------ | ------------------------------------------------- | -| `all` | Усі етапи Full Release Validation. | -| `ci` | Лише дочірній ручний full CI. | -| `plugin-prerelease` | Лише дочірній Plugin Prerelease. | -| `release-checks` | Усі етапи OpenClaw Release Checks. | -| `install-smoke` | Install Smoke через release checks. | -| `cross-os` | Cross-OS release checks. | -| `live-e2e` | Repo/live E2E і валідація Docker release-path. | -| `package` | Package Acceptance. | -| `qa` | QA parity плюс QA live lanes. | -| `qa-parity` | Лише QA parity lanes і звіт. | -| `qa-live` | Лише QA live Matrix і Telegram. | -| `npm-telegram` | Лише необов’язковий післяпублікаційний Telegram E2E. | +| Handle | Обсяг | +| ------------------- | --------------------------------------------------------------------- | +| `all` | Усі етапи Full Release Validation. | +| `ci` | Лише дочірній manual full CI. | +| `plugin-prerelease` | Лише дочірній Plugin Prerelease. | +| `release-checks` | Усі етапи OpenClaw Release Checks. | +| `install-smoke` | Install Smoke через release checks. | +| `cross-os` | Cross-OS release checks. | +| `live-e2e` | Repo/live E2E і валідація Docker release-path. | +| `package` | Package Acceptance. | +| `qa` | QA parity плюс QA live-лінії. | +| `qa-parity` | Лише QA parity-лінії та звіт. | +| `qa-live` | Лише QA live Matrix і Telegram. | +| `npm-telegram` | E2E Telegram для опублікованого пакета; потребує `npm_telegram_package_spec`. | -Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли впав один live-набір. -Дійсні ідентифікатори фільтрів визначені в багаторазовому workflow live/E2E, зокрема +Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли збій стався в одному live-наборі. +Дійсні filter ids визначені в багаторазовому workflow live/E2E, зокрема `docker-live-models`, `live-gateway-docker`, `live-gateway-anthropic-docker`, `live-gateway-google-docker`, `live-gateway-minimax-docker`, `live-gateway-advisory-docker`, `live-cli-backend-docker`, `live-acp-bind-docker` і `live-codex-harness-docker`. -## Докази, які слід зберігати +## Докази, які слід зберегти Зберігайте підсумок `Full Release Validation` як індекс рівня релізу. Він містить посилання -на ідентифікатори дочірніх запусків і таблиці найповільніших завдань. У разі збоїв спершу перевірте дочірній -workflow, а потім повторно запустіть найменший відповідний дескриптор вище. +на child run ids і включає таблиці найповільніших job. У разі збоїв спочатку перевірте дочірній +workflow, а потім повторно запустіть найменший відповідний handle вище. Корисні артефакти: - `release-package-under-test` з `OpenClaw Release Checks` - Артефакти Docker release-path у `.artifacts/docker-tests/` -- `package-under-test` Package Acceptance і артефакти Docker acceptance -- Артефакти Cross-OS release-check для кожної OS і набору +- `package-under-test` з Package Acceptance і артефакти Docker acceptance +- Артефакти Cross-OS release-check для кожної OS і suite - Артефакти QA parity, Matrix і Telegram ## Файли workflow