chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
680f7a893e
commit
424a200e53
@ -2,278 +2,278 @@
|
||||
read_when:
|
||||
- Вибір правильного підшляху plugin-sdk для імпорту Plugin
|
||||
- Аудит підшляхів bundled-plugin і допоміжних поверхонь
|
||||
summary: 'Каталог підшляхів Plugin SDK: які імпорти де розміщені, згруповано за областями'
|
||||
summary: 'Каталог підшляхів Plugin SDK: які імпорти де знаходяться, згруповано за областями'
|
||||
title: Підшляхи Plugin SDK
|
||||
x-i18n:
|
||||
generated_at: "2026-04-27T20:08:43Z"
|
||||
generated_at: "2026-04-27T21:05:09Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: b55ce02a25cfe9fe1bea2263bad31b50cc72c06affa451cc9cecac4404e70d79
|
||||
source_hash: ceab4e0a5ecceacbb06584fcc8fe47b394511822d9435cc1fd7bba1572492a63
|
||||
source_path: plugins/sdk-subpaths.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Plugin SDK надається як набір вузьких підшляхів у `openclaw/plugin-sdk/`.
|
||||
На цій сторінці наведено каталог найуживаніших підшляхів, згрупованих за призначенням. Згенерований
|
||||
повний список із понад 200 підшляхів розміщено в `scripts/lib/plugin-sdk-entrypoints.json`;
|
||||
зарезервовані допоміжні підшляхи bundled-plugin також наведені там, але вони є
|
||||
деталлю реалізації, якщо лише якась сторінка документації не просуває їх явно.
|
||||
Plugin SDK представлений як набір вузьких підшляхів у `openclaw/plugin-sdk/`.
|
||||
Ця сторінка каталогізує найуживаніші підшляхи, згруповані за призначенням. Згенерований
|
||||
повний список із понад 200 підшляхів міститься в `scripts/lib/plugin-sdk-entrypoints.json`;
|
||||
зарезервовані допоміжні підшляхи bundled-plugin також наведені там, але є деталями
|
||||
реалізації, якщо лише сторінка документації явно не рекомендує їх.
|
||||
|
||||
Щоб ознайомитися з посібником з розробки Plugin, див. [Огляд Plugin SDK](/uk/plugins/sdk-overview).
|
||||
Посібник з розробки Plugin див. у [Огляд Plugin SDK](/uk/plugins/sdk-overview).
|
||||
|
||||
## Точка входу Plugin
|
||||
## Вхідна точка Plugin
|
||||
|
||||
| Підшлях | Ключові експорти |
|
||||
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `plugin-sdk/plugin-entry` | `definePluginEntry` |
|
||||
| `plugin-sdk/core` | `defineChannelPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase`, `defineSetupPluginEntry`, `buildChannelConfigSchema` |
|
||||
| `plugin-sdk/config-schema` | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/migration` | Допоміжні елементи провайдера міграції, як-от `createMigrationItem`, константи причин, маркери статусу елементів, допоміжні засоби редагування та `summarizeMigrationItems` |
|
||||
| `plugin-sdk/migration-runtime` | Допоміжні засоби міграції під час виконання, як-от `copyMigrationFileItem` і `writeMigrationReport` |
|
||||
| Subpath | Ключові експорти |
|
||||
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `plugin-sdk/plugin-entry` | `definePluginEntry` |
|
||||
| `plugin-sdk/core` | `defineChannelPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase`, `defineSetupPluginEntry`, `buildChannelConfigSchema` |
|
||||
| `plugin-sdk/config-schema` | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/migration` | Допоміжні засоби елементів постачальника міграції, як-от `createMigrationItem`, константи причин, маркери статусу елементів, засоби редагування та `summarizeMigrationItems` |
|
||||
| `plugin-sdk/migration-runtime` | Допоміжні засоби міграції під час виконання, як-от `copyMigrationFileItem` і `writeMigrationReport` |
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Підшляхи каналів">
|
||||
| Підшлях | Ключові експорти |
|
||||
| Subpath | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/channel-core` | `defineChannelPluginEntry`, `defineSetupPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase` |
|
||||
| `plugin-sdk/config-schema` | Експорт кореневої Zod-схеми `openclaw.json` (`OpenClawSchema`) |
|
||||
| `plugin-sdk/channel-setup` | `createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`, `createOptionalChannelSetupWizard`, а також `DEFAULT_ACCOUNT_ID`, `createTopLevelChannelDmPolicy`, `setSetupChannelEnabled`, `splitSetupEntries` |
|
||||
| `plugin-sdk/setup` | Спільні допоміжні засоби майстра налаштування, запити allowlist, побудовники статусу налаштування |
|
||||
| `plugin-sdk/setup` | Спільні допоміжні засоби майстра налаштування, підказки allowlist, побудовники статусу налаштування |
|
||||
| `plugin-sdk/setup-runtime` | `createPatchedAccountSetupAdapter`, `createEnvPatchedAccountSetupAdapter`, `createSetupInputPresenceValidator`, `noteChannelLookupFailure`, `noteChannelLookupSummary`, `promptResolvedAllowFrom`, `splitSetupEntries`, `createAllowlistSetupWizardProxy`, `createDelegatedSetupWizardProxy` |
|
||||
| `plugin-sdk/setup-adapter-runtime` | `createEnvPatchedAccountSetupAdapter` |
|
||||
| `plugin-sdk/setup-tools` | `formatCliCommand`, `detectBinary`, `extractArchive`, `resolveBrewExecutable`, `formatDocsLink`, `CONFIG_DIR` |
|
||||
| `plugin-sdk/account-core` | Допоміжні засоби конфігурації та action gate для кількох облікових записів, допоміжні засоби резервного використання облікового запису за замовчуванням |
|
||||
| `plugin-sdk/account-id` | `DEFAULT_ACCOUNT_ID`, допоміжні засоби нормалізації id облікового запису |
|
||||
| `plugin-sdk/account-resolution` | Допоміжні засоби пошуку облікового запису + резервного використання облікового запису за замовчуванням |
|
||||
| `plugin-sdk/account-helpers` | Вузькі допоміжні засоби для списку облікових записів/дій з обліковими записами |
|
||||
| `plugin-sdk/account-core` | Допоміжні засоби конфігурації та керування доступом для кількох облікових записів, допоміжні засоби резервного використання типового облікового запису |
|
||||
| `plugin-sdk/account-id` | `DEFAULT_ACCOUNT_ID`, допоміжні засоби нормалізації ідентифікатора облікового запису |
|
||||
| `plugin-sdk/account-resolution` | Допоміжні засоби пошуку облікового запису та резервного використання типового |
|
||||
| `plugin-sdk/account-helpers` | Вузькі допоміжні засоби для списку облікових записів і дій з ними |
|
||||
| `plugin-sdk/channel-pairing` | `createChannelPairingController` |
|
||||
| `plugin-sdk/channel-reply-pipeline` | `createChannelReplyPipeline` |
|
||||
| `plugin-sdk/channel-config-helpers` | `createHybridChannelConfigAdapter` |
|
||||
| `plugin-sdk/channel-config-schema` | Спільні примітиви схеми конфігурації каналу та універсальний побудовник |
|
||||
| `plugin-sdk/channel-config-schema` | Спільні примітиви схеми конфігурації каналу та універсальний конструктор |
|
||||
| `plugin-sdk/channel-config-schema-legacy` | Застарілі схеми конфігурації bundled-channel лише для сумісності з bundled |
|
||||
| `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації/валідації користувацьких команд Telegram із резервною сумісністю контракту bundled |
|
||||
| `plugin-sdk/command-gating` | Вузькі допоміжні засоби gate авторизації команд |
|
||||
| `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації/перевірки користувацьких команд Telegram із резервною сумісністю bundled-contract |
|
||||
| `plugin-sdk/command-gating` | Вузькі допоміжні засоби авторизаційних обмежень для команд |
|
||||
| `plugin-sdk/channel-policy` | `resolveChannelGroupRequireMention` |
|
||||
| `plugin-sdk/channel-lifecycle` | `createAccountStatusSink`, допоміжні засоби життєвого циклу/завершення потоку чернеток |
|
||||
| `plugin-sdk/inbound-envelope` | Спільні допоміжні засоби для вхідної маршрутизації та побудови envelope |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Спільні допоміжні засоби для запису та диспетчеризації вхідних відповідей |
|
||||
| `plugin-sdk/channel-lifecycle` | `createAccountStatusSink`, допоміжні засоби життєвого циклу/фіналізації потоку чернеток |
|
||||
| `plugin-sdk/inbound-envelope` | Спільні допоміжні засоби маршрутизації вхідних повідомлень і побудови конвертів |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Спільні допоміжні засоби запису та диспетчеризації вхідних відповідей |
|
||||
| `plugin-sdk/messaging-targets` | Допоміжні засоби розбору/зіставлення цілей |
|
||||
| `plugin-sdk/outbound-media` | Спільні допоміжні засоби завантаження вихідних медіа |
|
||||
| `plugin-sdk/outbound-send-deps` | Полегшений пошук залежностей вихідного надсилання для адаптерів каналів |
|
||||
| `plugin-sdk/outbound-runtime` | Допоміжні засоби вихідної доставки, ідентичності, делегата надсилання, сесій, форматування та планування payload |
|
||||
| `plugin-sdk/outbound-send-deps` | Полегшений пошук залежностей надсилання вихідних повідомлень для адаптерів каналів |
|
||||
| `plugin-sdk/outbound-runtime` | Допоміжні засоби доставки вихідних повідомлень, ідентичності, делегата надсилання, сеансу, форматування та планування payload |
|
||||
| `plugin-sdk/poll-runtime` | Вузькі допоміжні засоби нормалізації опитувань |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Допоміжні засоби життєвого циклу прив’язок потоків і адаптерів |
|
||||
| `plugin-sdk/agent-media-payload` | Застарілий побудовник media payload агента |
|
||||
| `plugin-sdk/conversation-runtime` | Допоміжні засоби прив’язки розмов/потоків, спарювання та налаштованих прив’язок |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Допоміжні засоби життєвого циклу прив’язок потоків та адаптерів |
|
||||
| `plugin-sdk/agent-media-payload` | Застарілий конструктор payload медіа агента |
|
||||
| `plugin-sdk/conversation-runtime` | Допоміжні засоби прив’язки розмов/потоків, pairing і налаштованих прив’язок |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Допоміжний засіб знімка конфігурації під час виконання |
|
||||
| `plugin-sdk/runtime-group-policy` | Допоміжні засоби визначення групової політики під час виконання |
|
||||
| `plugin-sdk/channel-status` | Спільні допоміжні засоби знімка/підсумку статусу каналу |
|
||||
| `plugin-sdk/channel-status` | Спільні допоміжні засоби знімків/підсумків статусу каналу |
|
||||
| `plugin-sdk/channel-config-primitives` | Вузькі примітиви схеми конфігурації каналу |
|
||||
| `plugin-sdk/channel-config-writes` | Допоміжні засоби авторизації запису конфігурації каналу |
|
||||
| `plugin-sdk/channel-plugin-common` | Спільні prelude-експорти Plugin каналу |
|
||||
| `plugin-sdk/allowlist-config-edit` | Допоміжні засоби редагування/читання конфігурації allowlist |
|
||||
| `plugin-sdk/group-access` | Спільні допоміжні засоби ухвалення рішень щодо доступу груп |
|
||||
| `plugin-sdk/direct-dm` | Спільні допоміжні засоби auth/guard для прямих DM |
|
||||
| `plugin-sdk/group-access` | Спільні допоміжні засоби рішень щодо доступу до груп |
|
||||
| `plugin-sdk/direct-dm` | Спільні допоміжні засоби авторизації/захисту direct-DM |
|
||||
| `plugin-sdk/interactive-runtime` | Семантичне представлення повідомлень, доставка та застарілі допоміжні засоби інтерактивних відповідей. Див. [Представлення повідомлень](/uk/plugins/message-presentation) |
|
||||
| `plugin-sdk/channel-inbound` | Сумісний barrel для debounce вхідних повідомлень, зіставлення згадок, допоміжних засобів політики згадок і допоміжних засобів envelope |
|
||||
| `plugin-sdk/channel-inbound` | Сумісний barrel для debounce вхідних повідомлень, зіставлення згадок, допоміжних засобів політики згадок і допоміжних засобів конвертів |
|
||||
| `plugin-sdk/channel-inbound-debounce` | Вузькі допоміжні засоби debounce вхідних повідомлень |
|
||||
| `plugin-sdk/channel-mention-gating` | Вузькі допоміжні засоби політики згадок і тексту згадок без ширшої поверхні вхідного runtime |
|
||||
| `plugin-sdk/channel-envelope` | Вузькі допоміжні засоби форматування вхідного envelope |
|
||||
| `plugin-sdk/channel-location` | Допоміжні засоби контексту та форматування розташування каналу |
|
||||
| `plugin-sdk/channel-logging` | Допоміжні засоби логування каналу для відкинутих вхідних повідомлень і збоїв typing/ack |
|
||||
| `plugin-sdk/channel-mention-gating` | Вузькі допоміжні засоби політики згадок і тексту згадок без ширшої поверхні runtime для вхідних повідомлень |
|
||||
| `plugin-sdk/channel-envelope` | Вузькі допоміжні засоби форматування конвертів вхідних повідомлень |
|
||||
| `plugin-sdk/channel-location` | Допоміжні засоби контексту розташування каналу та форматування |
|
||||
| `plugin-sdk/channel-logging` | Допоміжні засоби журналювання каналу для відкидання вхідних повідомлень і збоїв typing/ack |
|
||||
| `plugin-sdk/channel-send-result` | Типи результатів відповіді |
|
||||
| `plugin-sdk/channel-actions` | Допоміжні засоби дій із повідомленнями каналу, а також застарілі допоміжні засоби native schema, збережені для сумісності Plugin |
|
||||
| `plugin-sdk/channel-targets` | Допоміжні засоби розбору/зіставлення цілей |
|
||||
| `plugin-sdk/channel-contract` | Типи контракту каналу |
|
||||
| `plugin-sdk/channel-feedback` | Підключення feedback/reaction |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби контрактів секретів, як-от `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment`, і типи цілей секретів |
|
||||
| `plugin-sdk/channel-contract` | Типи контрактів каналу |
|
||||
| `plugin-sdk/channel-feedback` | Підключення відгуків/реакцій |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби secret-contract, як-от `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment`, і типи цілей секретів |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи провайдерів">
|
||||
| Підшлях | Ключові експорти |
|
||||
| Subpath | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/lmstudio` | Підтримуваний фасад провайдера LM Studio для налаштування, виявлення каталогу та підготовки моделей під час виконання |
|
||||
| `plugin-sdk/lmstudio-runtime` | Підтримуваний фасад runtime LM Studio для локальних типових значень сервера, виявлення моделей, заголовків запитів і допоміжних засобів завантажених моделей |
|
||||
| `plugin-sdk/lmstudio-runtime` | Підтримуваний runtime-фасад LM Studio для типових параметрів локального сервера, виявлення моделей, заголовків запитів і допоміжних засобів завантажених моделей |
|
||||
| `plugin-sdk/provider-setup` | Кураторські допоміжні засоби налаштування локальних/self-hosted провайдерів |
|
||||
| `plugin-sdk/self-hosted-provider-setup` | Сфокусовані допоміжні засоби налаштування self-hosted провайдерів, сумісних з OpenAI |
|
||||
| `plugin-sdk/cli-backend` | Типові значення backend CLI + константи watchdog |
|
||||
| `plugin-sdk/provider-auth-runtime` | Допоміжні засоби визначення API key під час виконання для Plugin провайдерів |
|
||||
| `plugin-sdk/provider-auth-api-key` | Допоміжні засоби онбордингу API key/запису профілю, як-от `upsertApiKeyProfile` |
|
||||
| `plugin-sdk/provider-auth-result` | Стандартний побудовник результату auth OAuth |
|
||||
| `plugin-sdk/cli-backend` | Типові значення CLI backend і константи watchdog |
|
||||
| `plugin-sdk/provider-auth-runtime` | Допоміжні засоби визначення API-ключів під час виконання для Plugin провайдерів |
|
||||
| `plugin-sdk/provider-auth-api-key` | Допоміжні засоби онбордингу/запису профілю API-ключа, як-от `upsertApiKeyProfile` |
|
||||
| `plugin-sdk/provider-auth-result` | Стандартний конструктор результату OAuth-автентифікації |
|
||||
| `plugin-sdk/provider-auth-login` | Спільні допоміжні засоби інтерактивного входу для Plugin провайдерів |
|
||||
| `plugin-sdk/provider-env-vars` | Допоміжні засоби пошуку auth env var для провайдерів |
|
||||
| `plugin-sdk/provider-env-vars` | Допоміжні засоби пошуку env vars автентифікації провайдера |
|
||||
| `plugin-sdk/provider-auth` | `createProviderApiKeyAuthMethod`, `ensureApiKeyFromOptionEnvOrPrompt`, `upsertAuthProfile`, `upsertApiKeyProfile`, `writeOAuthCredentials` |
|
||||
| `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, спільні побудовники політик replay, допоміжні засоби endpoint провайдерів і допоміжні засоби нормалізації id моделей, як-от `normalizeNativeXaiModelId` |
|
||||
| `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, спільні конструктори політик replay, допоміжні засоби endpoint провайдерів і допоміжні засоби нормалізації model-id, як-от `normalizeNativeXaiModelId` |
|
||||
| `plugin-sdk/provider-catalog-shared` | `findCatalogTemplate`, `buildSingleProviderApiKeyCatalog`, `supportsNativeStreamingUsageCompat`, `applyProviderNativeStreamingUsageCompat` |
|
||||
| `plugin-sdk/provider-http` | Універсальні допоміжні засоби HTTP/можливостей endpoint провайдера, HTTP-помилки провайдера та допоміжні засоби multipart form для аудіотранскрипції |
|
||||
| `plugin-sdk/provider-http` | Універсальні допоміжні засоби HTTP/endpoint-можливостей провайдерів, помилки HTTP провайдерів і допоміжні засоби multipart form для транскрибування аудіо |
|
||||
| `plugin-sdk/provider-web-fetch-contract` | Вузькі допоміжні засоби контрактів конфігурації/вибору web-fetch, як-от `enablePluginInConfig` і `WebFetchProviderPlugin` |
|
||||
| `plugin-sdk/provider-web-fetch` | Допоміжні засоби реєстрації/кешу провайдера web-fetch |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Вузькі допоміжні засоби конфігурації/облікових даних web-search для провайдерів, яким не потрібне підключення enable Plugin |
|
||||
| `plugin-sdk/provider-web-search-contract` | Вузькі допоміжні засоби контрактів конфігурації/облікових даних web-search, як-от `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` і scope-овані setter/getter облікових даних |
|
||||
| `plugin-sdk/provider-web-search` | Допоміжні засоби реєстрації/кешу/runtime провайдера web-search |
|
||||
| `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, очищення схеми Gemini + діагностика та допоміжні засоби сумісності xAI, як-от `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-web-fetch` | Допоміжні засоби реєстрації/кешування web-fetch провайдерів |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Вузькі допоміжні засоби конфігурації/облікових даних web-search для провайдерів, яким не потрібне підключення активації Plugin |
|
||||
| `plugin-sdk/provider-web-search-contract` | Вузькі допоміжні засоби контрактів конфігурації/облікових даних web-search, як-от `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` і scoped setter/getter для облікових даних |
|
||||
| `plugin-sdk/provider-web-search` | Допоміжні засоби реєстрації/кешування/runtime для web-search провайдерів |
|
||||
| `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, очищення схем Gemini + діагностика та допоміжні засоби сумісності xAI, як-от `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-usage` | `fetchClaudeUsage` та подібні |
|
||||
| `plugin-sdk/provider-stream` | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, типи обгорток потоків і спільні допоміжні засоби обгорток Anthropic/Bedrock/DeepSeek V4/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
|
||||
| `plugin-sdk/provider-transport-runtime` | Допоміжні засоби native transport провайдерів, як-от guarded fetch, трансформації транспортних повідомлень і потоки подій writable transport |
|
||||
| `plugin-sdk/provider-onboard` | Допоміжні засоби патчів конфігурації онбордингу |
|
||||
| `plugin-sdk/provider-transport-runtime` | Допоміжні засоби native transport провайдерів, як-от guarded fetch, трансформації transport message і потоки подій writable transport |
|
||||
| `plugin-sdk/provider-onboard` | Допоміжні засоби виправлення конфігурації онбордингу |
|
||||
| `plugin-sdk/global-singleton` | Допоміжні засоби process-local singleton/map/cache |
|
||||
| `plugin-sdk/group-activation` | Вузькі допоміжні засоби режиму активації груп і розбору команд |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи auth і безпеки">
|
||||
| Підшлях | Ключові експорти |
|
||||
<Accordion title="Підшляхи автентифікації та безпеки">
|
||||
| Subpath | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/command-auth` | `resolveControlCommandGate`, допоміжні засоби реєстру команд, включно з форматуванням меню динамічних аргументів, допоміжні засоби авторизації відправника |
|
||||
| `plugin-sdk/command-status` | Побудовники повідомлень команд/довідки, як-от `buildCommandsMessagePaginated` і `buildHelpMessage` |
|
||||
| `plugin-sdk/approval-auth-runtime` | Допоміжні засоби визначення затверджувача та auth дій у межах того самого чату |
|
||||
| `plugin-sdk/approval-client-runtime` | Native допоміжні засоби профілю/фільтра затвердження exec |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Native адаптери можливостей/доставки затверджень |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Спільний допоміжний засіб визначення gateway затверджень |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Полегшені native допоміжні засоби завантаження адаптера затверджень для гарячих точок входу каналів |
|
||||
| `plugin-sdk/approval-handler-runtime` | Ширші допоміжні засоби runtime обробника затверджень; віддавайте перевагу вужчим адаптерним/gateway швам, якщо їх достатньо |
|
||||
| `plugin-sdk/approval-native-runtime` | Native допоміжні засоби цілей затвердження + прив’язки облікового запису |
|
||||
| `plugin-sdk/approval-reply-runtime` | Допоміжні засоби payload відповіді на затвердження exec/plugin |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби payload затвердження exec/plugin, native допоміжні засоби маршрутизації/runtime затверджень і допоміжні засоби структурованого відображення затверджень, як-от `formatApprovalDisplayPath` |
|
||||
| `plugin-sdk/command-status` | Конструктори повідомлень команд/довідки, як-от `buildCommandsMessagePaginated` і `buildHelpMessage` |
|
||||
| `plugin-sdk/approval-auth-runtime` | Допоміжні засоби визначення затверджувача та автентифікації дій у тому самому чаті |
|
||||
| `plugin-sdk/approval-client-runtime` | Допоміжні засоби профілів/фільтрів затвердження для native exec |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Native-адаптери можливостей/доставки затверджень |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Спільний допоміжний засіб визначення approval gateway |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Полегшені допоміжні засоби завантаження native-адаптера затвердження для гарячих вхідних точок каналів |
|
||||
| `plugin-sdk/approval-handler-runtime` | Ширші runtime-допоміжні засоби обробника затверджень; віддавайте перевагу вужчим adapter/gateway seams, якщо їх достатньо |
|
||||
| `plugin-sdk/approval-native-runtime` | Допоміжні засоби native target затвердження та прив’язки облікових записів |
|
||||
| `plugin-sdk/approval-reply-runtime` | Допоміжні засоби payload відповіді для затвердження exec/plugin |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби payload затвердження exec/plugin, native-допоміжні засоби маршрутизації/runtime затверджень і допоміжні засоби структурованого відображення затверджень, як-от `formatApprovalDisplayPath` |
|
||||
| `plugin-sdk/reply-dedupe` | Вузькі допоміжні засоби скидання дедуплікації вхідних відповідей |
|
||||
| `plugin-sdk/channel-contract-testing` | Вузькі допоміжні засоби тестування контракту каналу без широкого testing barrel |
|
||||
| `plugin-sdk/command-auth-native` | Native auth команд, форматування меню динамічних аргументів і native допоміжні засоби цільових сесій |
|
||||
| `plugin-sdk/channel-contract-testing` | Вузькі допоміжні засоби тестування контрактів каналів без широкого testing barrel |
|
||||
| `plugin-sdk/command-auth-native` | Native-автентифікація команд, форматування меню динамічних аргументів і native-допоміжні засоби session-target |
|
||||
| `plugin-sdk/command-detection` | Спільні допоміжні засоби виявлення команд |
|
||||
| `plugin-sdk/command-primitives-runtime` | Полегшені предикати тексту команд для гарячих шляхів каналів |
|
||||
| `plugin-sdk/command-surface` | Нормалізація тіла команд і допоміжні засоби command surface |
|
||||
| `plugin-sdk/command-surface` | Допоміжні засоби нормалізації тіла команди та command-surface |
|
||||
| `plugin-sdk/allow-from` | `formatAllowFromLowercase` |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби збирання контрактів секретів для поверхонь секретів channel/plugin |
|
||||
| `plugin-sdk/secret-ref-runtime` | Вузькі допоміжні засоби `coerceSecretRef` і типізації SecretRef для парсингу контрактів секретів/конфігурації |
|
||||
| `plugin-sdk/security-runtime` | Спільні допоміжні засоби довіри, gate для DM, зовнішнього вмісту, редагування чутливого тексту, порівняння секретів за сталий час і збирання секретів |
|
||||
| `plugin-sdk/ssrf-policy` | Допоміжні засоби політики SSRF для allowlist хостів і приватних мереж |
|
||||
| `plugin-sdk/ssrf-dispatcher` | Вузькі допоміжні засоби pinned dispatcher без широкої infra runtime surface |
|
||||
| `plugin-sdk/ssrf-runtime` | Допоміжні засоби pinned dispatcher, fetch із захистом від SSRF, помилка SSRF і допоміжні засоби політики SSRF |
|
||||
| `plugin-sdk/secret-input` | Допоміжні засоби парсингу введення секретів |
|
||||
| `plugin-sdk/webhook-ingress` | Допоміжні засоби запитів/цілей Webhook і приведення необроблених websocket/body |
|
||||
| `plugin-sdk/webhook-request-guards` | Допоміжні засоби розміру body/тайм-ауту запиту |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби збору secret-contract для поверхонь секретів channel/plugin |
|
||||
| `plugin-sdk/secret-ref-runtime` | Вузькі допоміжні засоби `coerceSecretRef` і типізації SecretRef для розбору secret-contract/config |
|
||||
| `plugin-sdk/security-runtime` | Спільні допоміжні засоби довіри, DM gating, зовнішнього контенту, редагування чутливого тексту, порівняння секретів за сталий час і збору секретів |
|
||||
| `plugin-sdk/ssrf-policy` | Допоміжні засоби allowlist хостів і політики SSRF для приватних мереж |
|
||||
| `plugin-sdk/ssrf-dispatcher` | Вузькі допоміжні засоби pinned-dispatcher без широкої infra runtime-поверхні |
|
||||
| `plugin-sdk/ssrf-runtime` | Допоміжні засоби pinned-dispatcher, fetch із захистом від SSRF, помилка SSRF і допоміжні засоби політики SSRF |
|
||||
| `plugin-sdk/secret-input` | Допоміжні засоби розбору введення секретів |
|
||||
| `plugin-sdk/webhook-ingress` | Допоміжні засоби запитів/цілей Webhook і приведення raw websocket/body |
|
||||
| `plugin-sdk/webhook-request-guards` | Допоміжні засоби для обмеження розміру body/timeout запиту |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи runtime і сховища">
|
||||
| Підшлях | Ключові експорти |
|
||||
| Subpath | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/runtime` | Широкі допоміжні засоби runtime/логування/резервного копіювання/встановлення Plugin |
|
||||
| `plugin-sdk/runtime-env` | Вузькі допоміжні засоби env runtime, логера, тайм-аутів, повторних спроб і backoff |
|
||||
| `plugin-sdk/browser-config` | Підтримуваний фасад конфігурації браузера для нормалізованих профілів/типових значень, парсингу CDP URL і допоміжних засобів auth browser-control |
|
||||
| `plugin-sdk/channel-runtime-context` | Універсальні допоміжні засоби реєстрації та пошуку channel runtime-context |
|
||||
| `plugin-sdk/runtime` | Широкі допоміжні засоби runtime/журналювання/резервного копіювання/встановлення Plugin |
|
||||
| `plugin-sdk/runtime-env` | Вузькі допоміжні засоби runtime env, logger, timeout, retry і backoff |
|
||||
| `plugin-sdk/browser-config` | Підтримуваний фасад конфігурації браузера для нормалізованого профілю/типових значень, розбору CDP URL і допоміжних засобів автентифікації browser-control |
|
||||
| `plugin-sdk/channel-runtime-context` | Універсальні допоміжні засоби реєстрації та пошуку runtime-context каналу |
|
||||
| `plugin-sdk/runtime-store` | `createPluginRuntimeStore` |
|
||||
| `plugin-sdk/plugin-runtime` | Спільні допоміжні засоби команд/хуків/http/інтерактивності Plugin |
|
||||
| `plugin-sdk/hook-runtime` | Спільні допоміжні засоби конвеєра Webhook/внутрішніх хуків |
|
||||
| `plugin-sdk/lazy-runtime` | Допоміжні засоби лінивого імпорту/прив’язки runtime, як-от `createLazyRuntimeModule`, `createLazyRuntimeMethod` і `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/plugin-runtime` | Спільні допоміжні засоби команд/hooks/http/interactive для Plugin |
|
||||
| `plugin-sdk/hook-runtime` | Спільні допоміжні засоби pipeline для Webhook/internal hooks |
|
||||
| `plugin-sdk/lazy-runtime` | Допоміжні засоби lazy-імпорту/прив’язки runtime, як-от `createLazyRuntimeModule`, `createLazyRuntimeMethod` і `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/process-runtime` | Допоміжні засоби exec процесів |
|
||||
| `plugin-sdk/cli-runtime` | Допоміжні засоби форматування CLI, очікування, версій, виклику аргументів і лінивих груп команд |
|
||||
| `plugin-sdk/gateway-runtime` | Допоміжні засоби клієнта Gateway, CLI RPC Gateway, помилок протоколу Gateway і патчів статусу каналу |
|
||||
| `plugin-sdk/config-types` | Поверхня конфігурації лише для типів для форм конфігурації Plugin, як-от `OpenClawConfig` і типів конфігурації каналів/провайдерів |
|
||||
| `plugin-sdk/cli-runtime` | Допоміжні засоби форматування CLI, wait, version, invocation аргументів і lazy command-group |
|
||||
| `plugin-sdk/gateway-runtime` | Допоміжні засоби клієнта Gateway, CLI RPC Gateway, помилок протоколу Gateway і patch-допоміжні засоби статусу каналу |
|
||||
| `plugin-sdk/config-types` | Поверхня конфігурації лише для типів для форм конфігурації Plugin, як-от `OpenClawConfig` і типи конфігурації каналів/провайдерів |
|
||||
| `plugin-sdk/plugin-config-runtime` | Допоміжні засоби пошуку конфігурації Plugin під час виконання, як-от `requireRuntimeConfig`, `resolvePluginConfigObject` і `resolveLivePluginConfigObject` |
|
||||
| `plugin-sdk/config-mutation` | Допоміжні засоби транзакційної мутації конфігурації, як-от `mutateConfigFile`, `replaceConfigFile` і `logConfigUpdated` |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Допоміжні засоби знімка конфігурації поточного процесу, як-от `getRuntimeConfig`, `getRuntimeConfigSnapshot` і setter-и тестових знімків |
|
||||
| `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації назв/описів команд Telegram і перевірки дублікатів/конфліктів, навіть коли bundled поверхня контракту Telegram недоступна |
|
||||
| `plugin-sdk/text-autolink-runtime` | Виявлення автопосилань на файли без широкого barrel `text-runtime` |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби затвердження exec/plugin, побудовники можливостей затвердження, допоміжні засоби auth/профілів, native допоміжні засоби маршрутизації/runtime і форматування шляху структурованого відображення затверджень |
|
||||
| `plugin-sdk/reply-runtime` | Спільні допоміжні засоби runtime вхідних повідомлень/відповідей, chunking, dispatch, Heartbeat, планувальник відповідей |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Допоміжні засоби знімка конфігурації поточного процесу, як-от `getRuntimeConfig`, `getRuntimeConfigSnapshot`, і setter-и тестових знімків |
|
||||
| `plugin-sdk/telegram-command-config` | Нормалізація назв/описів команд Telegram і перевірки дублікатів/конфліктів, навіть коли bundled Telegram contract surface недоступна |
|
||||
| `plugin-sdk/text-autolink-runtime` | Виявлення autolink посилань на файли без широкого text-runtime barrel |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби затвердження exec/plugin, конструктори можливостей затвердження, допоміжні засоби auth/profile, native-допоміжні засоби маршрутизації/runtime і форматування шляху структурованого відображення затвердження |
|
||||
| `plugin-sdk/reply-runtime` | Спільні runtime-допоміжні засоби вхідних повідомлень/відповідей, chunking, dispatch, Heartbeat, планувальник відповідей |
|
||||
| `plugin-sdk/reply-dispatch-runtime` | Вузькі допоміжні засоби dispatch/finalize відповідей і міток розмов |
|
||||
| `plugin-sdk/reply-history` | Спільні допоміжні засоби коротковіконної історії відповідей, як-от `buildHistoryContext`, `recordPendingHistoryEntry` і `clearHistoryEntriesIfEnabled` |
|
||||
| `plugin-sdk/reply-reference` | `createReplyReferencePlanner` |
|
||||
| `plugin-sdk/reply-chunking` | Вузькі допоміжні засоби chunking тексту/Markdown |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби шляху сховища сесій, ключів сесій, updated-at і мутації сховища |
|
||||
| `plugin-sdk/reply-chunking` | Вузькі допоміжні засоби chunking для text/markdown |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби шляху сховища сесій, session-key, updated-at і мутації сховища |
|
||||
| `plugin-sdk/cron-store-runtime` | Допоміжні засоби шляху/завантаження/збереження сховища Cron |
|
||||
| `plugin-sdk/state-paths` | Допоміжні засоби шляхів до каталогів state/OAuth |
|
||||
| `plugin-sdk/routing` | Допоміжні засоби прив’язки маршрутів/ключів сесій/облікових записів, як-от `resolveAgentRoute`, `buildAgentSessionKey` і `resolveDefaultAgentBoundAccountId` |
|
||||
| `plugin-sdk/status-helpers` | Спільні допоміжні засоби підсумку статусу каналу/облікового запису, типових значень runtime state і метаданих проблем |
|
||||
| `plugin-sdk/state-paths` | Допоміжні засоби шляхів каталогів state/OAuth |
|
||||
| `plugin-sdk/routing` | Допоміжні засоби route/session-key/прив’язки облікових записів, як-от `resolveAgentRoute`, `buildAgentSessionKey` і `resolveDefaultAgentBoundAccountId` |
|
||||
| `plugin-sdk/status-helpers` | Спільні допоміжні засоби підсумків статусу каналу/облікового запису, типові значення runtime-state і допоміжні засоби метаданих проблем |
|
||||
| `plugin-sdk/target-resolver-runtime` | Спільні допоміжні засоби визначення цілей |
|
||||
| `plugin-sdk/string-normalization-runtime` | Допоміжні засоби нормалізації slug/рядків |
|
||||
| `plugin-sdk/request-url` | Витягування рядкових URL із fetch/request-подібних входів |
|
||||
| `plugin-sdk/run-command` | Виконавець команд із таймером і нормалізованими результатами stdout/stderr |
|
||||
| `plugin-sdk/param-readers` | Поширені засоби читання параметрів tool/CLI |
|
||||
| `plugin-sdk/run-command` | Runner команд із таймером і нормалізованими результатами stdout/stderr |
|
||||
| `plugin-sdk/param-readers` | Типові читачі параметрів tool/CLI |
|
||||
| `plugin-sdk/tool-payload` | Витягування нормалізованих payload з об’єктів результатів tool |
|
||||
| `plugin-sdk/tool-send` | Витягування канонічних полів цілей надсилання з аргументів tool |
|
||||
| `plugin-sdk/temp-path` | Спільні допоміжні засоби шляхів тимчасових завантажень |
|
||||
| `plugin-sdk/logging-core` | Допоміжні засоби логера підсистеми та редагування |
|
||||
| `plugin-sdk/markdown-table-runtime` | Допоміжні засоби режиму й перетворення таблиць Markdown |
|
||||
| `plugin-sdk/tool-send` | Витягування канонічних полів цілі надсилання з аргументів tool |
|
||||
| `plugin-sdk/temp-path` | Спільні допоміжні засоби шляхів тимчасового завантаження |
|
||||
| `plugin-sdk/logging-core` | Допоміжні засоби subsystem logger і редагування |
|
||||
| `plugin-sdk/markdown-table-runtime` | Допоміжні засоби режиму й конвертації таблиць Markdown |
|
||||
| `plugin-sdk/model-session-runtime` | Допоміжні засоби перевизначення моделі/сесії, як-от `applyModelOverrideToSessionEntry` і `resolveAgentMaxConcurrent` |
|
||||
| `plugin-sdk/talk-config-runtime` | Допоміжні засоби визначення конфігурації talk-провайдера |
|
||||
| `plugin-sdk/json-store` | Невеликі допоміжні засоби читання/запису стану JSON |
|
||||
| `plugin-sdk/file-lock` | Допоміжні засоби повторно вхідного file lock |
|
||||
| `plugin-sdk/persistent-dedupe` | Допоміжні засоби кешу дедуплікації з дисковим зберіганням |
|
||||
| `plugin-sdk/talk-config-runtime` | Допоміжні засоби визначення конфігурації talk provider |
|
||||
| `plugin-sdk/json-store` | Допоміжні засоби читання/запису малого JSON state |
|
||||
| `plugin-sdk/file-lock` | Допоміжні засоби повторно вхідних file-lock |
|
||||
| `plugin-sdk/persistent-dedupe` | Допоміжні засоби disk-backed кешу дедуплікації |
|
||||
| `plugin-sdk/acp-runtime` | Допоміжні засоби runtime/сесій ACP і dispatch відповідей |
|
||||
| `plugin-sdk/acp-binding-resolve-runtime` | Визначення прив’язок ACP лише для читання без імпортів запуску життєвого циклу |
|
||||
| `plugin-sdk/agent-config-primitives` | Вузькі примітиви схеми конфігурації runtime агента |
|
||||
| `plugin-sdk/boolean-param` | Засіб читання нечіткого булевого параметра |
|
||||
| `plugin-sdk/dangerous-name-runtime` | Допоміжні засоби визначення збігів небезпечних назв |
|
||||
| `plugin-sdk/device-bootstrap` | Допоміжні засоби початкового налаштування пристрою та токенів спарювання |
|
||||
| `plugin-sdk/extension-shared` | Спільні примітиви допоміжних засобів passive-channel, статусу та ambient proxy |
|
||||
| `plugin-sdk/models-provider-runtime` | Допоміжні засоби відповідей команди `/models`/провайдера |
|
||||
| `plugin-sdk/skill-commands-runtime` | Допоміжні засоби виведення списку команд Skills |
|
||||
| `plugin-sdk/native-command-registry` | Допоміжні засоби реєстру/build/serialize native команд |
|
||||
| `plugin-sdk/agent-harness` | Експериментальна surface довіреного Plugin для низькорівневих harness агента: типи harness, допоміжні засоби steer/abort активного запуску, допоміжні засоби мосту tool OpenClaw, допоміжні засоби політики tool плану runtime, класифікація результатів terminal, допоміжні засоби форматування/деталізації прогресу tool і утиліти результатів спроб |
|
||||
| `plugin-sdk/provider-zai-endpoint` | Допоміжні засоби виявлення endpoint Z.AI |
|
||||
| `plugin-sdk/async-lock-runtime` | Допоміжний засіб process-local async lock для невеликих файлів стану runtime |
|
||||
| `plugin-sdk/channel-activity-runtime` | Допоміжний засіб телеметрії активності каналу |
|
||||
| `plugin-sdk/concurrency-runtime` | Допоміжний засіб обмеженої конкурентності асинхронних завдань |
|
||||
| `plugin-sdk/dedupe-runtime` | Допоміжні засоби кешу дедуплікації в пам’яті |
|
||||
| `plugin-sdk/delivery-queue-runtime` | Допоміжний засіб осушення черги очікуваної вихідної доставки |
|
||||
| `plugin-sdk/file-access-runtime` | Допоміжні засоби безпечних шляхів локальних файлів і джерел медіа |
|
||||
| `plugin-sdk/agent-config-primitives` | Вузькі примітиви runtime config-schema агента |
|
||||
| `plugin-sdk/boolean-param` | Гнучкий читач boolean-параметрів |
|
||||
| `plugin-sdk/dangerous-name-runtime` | Допоміжні засоби визначення збігів небезпечних імен |
|
||||
| `plugin-sdk/device-bootstrap` | Допоміжні засоби bootstrap пристрою та токенів pairing |
|
||||
| `plugin-sdk/extension-shared` | Спільні примітиви допоміжних засобів passive-channel, статусу й ambient proxy |
|
||||
| `plugin-sdk/models-provider-runtime` | Допоміжні засоби відповідей `/models` command/provider |
|
||||
| `plugin-sdk/skill-commands-runtime` | Допоміжні засоби списку команд Skills |
|
||||
| `plugin-sdk/native-command-registry` | Допоміжні засоби реєстру/build/serialize native-команд |
|
||||
| `plugin-sdk/agent-harness` | Експериментальна trusted-plugin поверхня для низькорівневих harness агента: типи harness, допоміжні засоби steer/abort для active-run, допоміжні засоби мосту OpenClaw tool, допоміжні засоби політики runtime-plan tool, класифікація результатів terminal, допоміжні засоби форматування/деталізації прогресу tool і утиліти результатів спроб |
|
||||
| `plugin-sdk/provider-zai-endpoint` | Допоміжні засоби виявлення endpoint Z.A.I |
|
||||
| `plugin-sdk/async-lock-runtime` | Допоміжний засіб process-local async lock для малих файлів runtime state |
|
||||
| `plugin-sdk/channel-activity-runtime` | Допоміжний засіб telemetry активності каналу |
|
||||
| `plugin-sdk/concurrency-runtime` | Допоміжний засіб обмеженої async-конкурентності задач |
|
||||
| `plugin-sdk/dedupe-runtime` | Допоміжні засоби in-memory кешу дедуплікації |
|
||||
| `plugin-sdk/delivery-queue-runtime` | Допоміжний засіб drain для pending-delivery вихідних повідомлень |
|
||||
| `plugin-sdk/file-access-runtime` | Допоміжні засоби безпечних шляхів до локальних файлів і джерел медіа |
|
||||
| `plugin-sdk/heartbeat-runtime` | Допоміжні засоби подій і видимості Heartbeat |
|
||||
| `plugin-sdk/number-runtime` | Допоміжний засіб приведення числових значень |
|
||||
| `plugin-sdk/number-runtime` | Допоміжний засіб числового приведення |
|
||||
| `plugin-sdk/secure-random-runtime` | Допоміжні засоби безпечних токенів/UUID |
|
||||
| `plugin-sdk/system-event-runtime` | Допоміжні засоби черги системних подій |
|
||||
| `plugin-sdk/transport-ready-runtime` | Допоміжний засіб очікування готовності транспорту |
|
||||
| `plugin-sdk/infra-runtime` | Застарілий shim сумісності; використовуйте наведені вище сфокусовані підшляхи runtime |
|
||||
| `plugin-sdk/collection-runtime` | Невеликі допоміжні засоби обмеженого кешу |
|
||||
| `plugin-sdk/diagnostic-runtime` | Допоміжні засоби діагностичних прапорців, подій і trace context |
|
||||
| `plugin-sdk/transport-ready-runtime` | Допоміжний засіб очікування готовності transport |
|
||||
| `plugin-sdk/infra-runtime` | Застарілий shim сумісності; використовуйте сфокусовані runtime-підшляхи вище |
|
||||
| `plugin-sdk/collection-runtime` | Допоміжні засоби малого обмеженого кешу |
|
||||
| `plugin-sdk/diagnostic-runtime` | Допоміжні засоби diagnostic flag, event і trace-context |
|
||||
| `plugin-sdk/error-runtime` | Допоміжні засоби графа помилок, форматування, спільної класифікації помилок, `isApprovalNotFoundError` |
|
||||
| `plugin-sdk/fetch-runtime` | Допоміжні засоби обгорнутого fetch, proxy і pinned lookup |
|
||||
| `plugin-sdk/runtime-fetch` | Runtime fetch з урахуванням dispatcher без імпортів proxy/guarded-fetch |
|
||||
| `plugin-sdk/response-limit-runtime` | Засіб читання body відповіді з обмеженням без широкої media runtime surface |
|
||||
| `plugin-sdk/session-binding-runtime` | Поточний стан прив’язки розмови без маршрутизації налаштованих прив’язок або сховищ спарювання |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби сховища сесій без широких імпортів запису/обслуговування конфігурації |
|
||||
| `plugin-sdk/context-visibility-runtime` | Допоміжні засоби визначення видимості контексту та фільтрації додаткового контексту без широких імпортів конфігурації/безпеки |
|
||||
| `plugin-sdk/string-coerce-runtime` | Вузькі допоміжні засоби приведення та нормалізації примітивних записів/рядків без імпортів markdown/логування |
|
||||
| `plugin-sdk/runtime-fetch` | Dispatcher-aware runtime fetch без імпортів proxy/guarded-fetch |
|
||||
| `plugin-sdk/response-limit-runtime` | Обмежений reader тіла відповіді без широкої media runtime-поверхні |
|
||||
| `plugin-sdk/session-binding-runtime` | Поточний стан прив’язки розмови без маршрутизації налаштованих прив’язок або pairing stores |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби session-store без широких імпортів запису/обслуговування конфігурації |
|
||||
| `plugin-sdk/context-visibility-runtime` | Допоміжні засоби визначення видимості контексту та фільтрації додаткового контексту без широких імпортів config/security |
|
||||
| `plugin-sdk/string-coerce-runtime` | Вузькі допоміжні засоби приведення й нормалізації primitive record/string без імпортів markdown/logging |
|
||||
| `plugin-sdk/host-runtime` | Допоміжні засоби нормалізації hostname і SCP host |
|
||||
| `plugin-sdk/retry-runtime` | Допоміжні засоби конфігурації повторних спроб і виконавця повторних спроб |
|
||||
| `plugin-sdk/agent-runtime` | Допоміжні засоби каталогів/ідентичності/робочого простору агента |
|
||||
| `plugin-sdk/directory-runtime` | Запит/дедуплікація каталогів на основі конфігурації |
|
||||
| `plugin-sdk/retry-runtime` | Допоміжні засоби конфігурації retry і runner retry |
|
||||
| `plugin-sdk/agent-runtime` | Допоміжні засоби каталогу/ідентичності/workspace агента |
|
||||
| `plugin-sdk/directory-runtime` | Запит/dedup каталогів на основі конфігурації |
|
||||
| `plugin-sdk/keyed-async-queue` | `KeyedAsyncQueue` |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи можливостей і тестування">
|
||||
| Підшлях | Ключові експорти |
|
||||
| Subpath | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/media-runtime` | Спільні допоміжні засоби fetch/transform/store для медіа, а також побудовники media payload |
|
||||
| `plugin-sdk/media-store` | Вузькі допоміжні засоби media store, як-от `saveMediaBuffer` |
|
||||
| `plugin-sdk/media-generation-runtime` | Спільні допоміжні засоби failover для генерації медіа, вибір кандидатів і повідомлення про відсутні моделі |
|
||||
| `plugin-sdk/media-understanding` | Типи провайдерів для розуміння медіа, а також провайдер-орієнтовані експорти допоміжних засобів для зображень/аудіо |
|
||||
| `plugin-sdk/text-runtime` | Спільні допоміжні засоби тексту/Markdown/логування, як-от видалення тексту, видимого асистенту, допоміжні засоби рендерингу/chunking/таблиць Markdown, допоміжні засоби редагування, допоміжні засоби directive tag і утиліти безпечного тексту |
|
||||
| `plugin-sdk/media-runtime` | Спільні допоміжні засоби fetch/transform/store для медіа, а також конструктори media payload |
|
||||
| `plugin-sdk/media-store` | Вузькі допоміжні засоби сховища медіа, як-от `saveMediaBuffer` |
|
||||
| `plugin-sdk/media-generation-runtime` | Спільні допоміжні засоби failover для генерації медіа, вибору кандидатів і повідомлень про відсутню модель |
|
||||
| `plugin-sdk/media-understanding` | Типи провайдерів розуміння медіа, а також орієнтовані на провайдерів експорти допоміжних засобів для зображень/аудіо |
|
||||
| `plugin-sdk/text-runtime` | Спільні допоміжні засоби text/markdown/logging, як-от вилучення тексту, видимого асистенту, допоміжні засоби рендерингу/chunking/table для markdown, допоміжні засоби редагування, допоміжні засоби тегів директив і утиліти безпечного тексту |
|
||||
| `plugin-sdk/text-chunking` | Допоміжний засіб chunking вихідного тексту |
|
||||
| `plugin-sdk/speech` | Типи провайдерів мовлення, а також провайдер-орієнтовані експорти директив, реєстру, валідації та допоміжних засобів мовлення |
|
||||
| `plugin-sdk/speech` | Типи провайдерів мовлення, а також орієнтовані на провайдерів експорти директив, реєстру, валідації та допоміжних засобів мовлення |
|
||||
| `plugin-sdk/speech-core` | Спільні типи провайдерів мовлення, експорти реєстру, директив, нормалізації та допоміжних засобів мовлення |
|
||||
| `plugin-sdk/realtime-transcription` | Типи провайдерів транскрипції в реальному часі, допоміжні засоби реєстру та спільний допоміжний засіб сесій WebSocket |
|
||||
| `plugin-sdk/realtime-transcription` | Типи провайдерів транскрибування в реальному часі, допоміжні засоби реєстру та спільний допоміжний засіб WebSocket session |
|
||||
| `plugin-sdk/realtime-voice` | Типи провайдерів голосу в реальному часі та допоміжні засоби реєстру |
|
||||
| `plugin-sdk/image-generation` | Типи провайдерів генерації зображень |
|
||||
| `plugin-sdk/image-generation-core` | Спільні типи генерації зображень, допоміжні засоби failover, auth і реєстру |
|
||||
| `plugin-sdk/music-generation` | Типи провайдерів/запитів/результатів генерації музики |
|
||||
| `plugin-sdk/music-generation-core` | Спільні типи генерації музики, допоміжні засоби failover, пошук провайдера та парсинг model ref |
|
||||
| `plugin-sdk/music-generation-core` | Спільні типи генерації музики, допоміжні засоби failover, пошук провайдера та розбір model-ref |
|
||||
| `plugin-sdk/video-generation` | Типи провайдерів/запитів/результатів генерації відео |
|
||||
| `plugin-sdk/video-generation-core` | Спільні типи генерації відео, допоміжні засоби failover, пошук провайдера та парсинг model ref |
|
||||
| `plugin-sdk/video-generation-core` | Спільні типи генерації відео, допоміжні засоби failover, пошук провайдера та розбір model-ref |
|
||||
| `plugin-sdk/webhook-targets` | Допоміжні засоби реєстру цілей Webhook і встановлення маршрутів |
|
||||
| `plugin-sdk/webhook-path` | Допоміжні засоби нормалізації шляхів Webhook |
|
||||
| `plugin-sdk/webhook-path` | Допоміжні засоби нормалізації шляху Webhook |
|
||||
| `plugin-sdk/web-media` | Спільні допоміжні засоби завантаження віддалених/локальних медіа |
|
||||
| `plugin-sdk/zod` | Повторно експортований `zod` для користувачів Plugin SDK |
|
||||
| `plugin-sdk/testing` | Публічні допоміжні засоби тестування extensions, зокрема `installCommonResolveTargetErrorCases`, `shouldAckReaction`, `writeSkill`, `createTestRegistry` і завантаження env для live generation |
|
||||
| `plugin-sdk/zod` | Повторно експортований `zod` для споживачів Plugin SDK |
|
||||
| `plugin-sdk/testing` | Публічні допоміжні засоби тестування розширень, включно з mock-об’єктами реєстру/runtime Plugin, допоміжними засобами schema/media/live-test, `installCommonResolveTargetErrorCases`, `writeSkill`, `createTestRegistry` і завантаженням env для live generation |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи пам’яті">
|
||||
| Підшлях | Ключові експорти |
|
||||
| Subpath | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/memory-core` | Поверхня допоміжних засобів bundled memory-core для менеджера/конфігурації/файлів/допоміжних засобів CLI |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Фасад runtime індексації/пошуку пам’яті |
|
||||
| `plugin-sdk/memory-core` | Поверхня допоміжних засобів bundled memory-core для manager/config/file/CLI helpers |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Runtime-фасад індексації/пошуку пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-foundation` | Експорти foundation engine хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-embeddings` | Контракти embedding хоста пам’яті, доступ до реєстру, локальний провайдер і універсальні пакетні/віддалені допоміжні засоби |
|
||||
| `plugin-sdk/memory-core-host-engine-embeddings` | Контракти embeddings хоста пам’яті, доступ до реєстру, локальний провайдер і універсальні пакетні/віддалені допоміжні засоби |
|
||||
| `plugin-sdk/memory-core-host-engine-qmd` | Експорти QMD engine хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-storage` | Експорти storage engine хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-multimodal` | Мультимодальні допоміжні засоби хоста пам’яті |
|
||||
@ -281,27 +281,27 @@ x-i18n:
|
||||
| `plugin-sdk/memory-core-host-secret` | Допоміжні засоби секретів хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-events` | Допоміжні засоби журналу подій хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-status` | Допоміжні засоби статусу хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Допоміжні засоби runtime CLI хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Допоміжні засоби core runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Runtime-допоміжні засоби CLI хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Основні runtime-допоміжні засоби хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-files` | Допоміжні засоби файлів/runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-core` | Незалежний від постачальника псевдонім для допоміжних засобів core runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-events` | Незалежний від постачальника псевдонім для допоміжних засобів журналу подій хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-files` | Незалежний від постачальника псевдонім для допоміжних засобів файлів/runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-markdown` | Спільні допоміжні засоби керованого Markdown для Plugin, суміжних із пам’яттю |
|
||||
| `plugin-sdk/memory-host-search` | Фасад runtime Active Memory для доступу до менеджера пошуку |
|
||||
| `plugin-sdk/memory-host-status` | Незалежний від постачальника псевдонім для допоміжних засобів статусу хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-core` | Нейтральний до вендора псевдонім для основних runtime-допоміжних засобів хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-events` | Нейтральний до вендора псевдонім для допоміжних засобів журналу подій хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-files` | Нейтральний до вендора псевдонім для допоміжних засобів файлів/runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-markdown` | Спільні допоміжні засоби керованого markdown для Plugin, пов’язаних із пам’яттю |
|
||||
| `plugin-sdk/memory-host-search` | Runtime-фасад Active Memory для доступу до search-manager |
|
||||
| `plugin-sdk/memory-host-status` | Нейтральний до вендора псевдонім для допоміжних засобів статусу хоста пам’яті |
|
||||
| `plugin-sdk/memory-lancedb` | Поверхня допоміжних засобів bundled memory-lancedb |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Зарезервовані підшляхи bundled-helper">
|
||||
| Сімейство | Поточні підшляхи | Призначення |
|
||||
| Family | Поточні підшляхи | Призначення |
|
||||
| --- | --- | --- |
|
||||
| Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Допоміжні засоби підтримки bundled browser Plugin. `browser-profiles` експортує `resolveBrowserConfig`, `resolveProfile`, `ResolvedBrowserConfig`, `ResolvedBrowserProfile` і `ResolvedBrowserTabCleanupConfig` для нормалізованої форми `browser.tabCleanup`. `browser-support` залишається compatibility barrel. |
|
||||
| Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Допоміжні засоби підтримки bundled browser plugin. `browser-profiles` експортує `resolveBrowserConfig`, `resolveProfile`, `ResolvedBrowserConfig`, `ResolvedBrowserProfile` і `ResolvedBrowserTabCleanupConfig` для нормалізованої форми `browser.tabCleanup`. `browser-support` залишається compatibility barrel. |
|
||||
| Matrix | `plugin-sdk/matrix`, `plugin-sdk/matrix-helper`, `plugin-sdk/matrix-runtime-heavy`, `plugin-sdk/matrix-runtime-shared`, `plugin-sdk/matrix-runtime-surface`, `plugin-sdk/matrix-surface`, `plugin-sdk/matrix-thread-bindings` | Поверхня допоміжних засобів/runtime bundled Matrix |
|
||||
| Line | `plugin-sdk/line`, `plugin-sdk/line-core`, `plugin-sdk/line-runtime`, `plugin-sdk/line-surface` | Поверхня допоміжних засобів/runtime bundled LINE |
|
||||
| IRC | `plugin-sdk/irc`, `plugin-sdk/irc-surface` | Поверхня допоміжних засобів bundled IRC |
|
||||
| Допоміжні засоби, специфічні для каналу | `plugin-sdk/googlechat`, `plugin-sdk/googlechat-runtime-shared`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu`, `plugin-sdk/feishu-conversation`, `plugin-sdk/feishu-setup`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/telegram-command-ui`, `plugin-sdk/tlon`, `plugin-sdk/twitch`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup` | Застарілі шви сумісності/допоміжних засобів bundled channel. Нові Plugin мають імпортувати універсальні підшляхи SDK або локальні barrel Plugin. |
|
||||
| Допоміжні засоби auth/специфічні для Plugin | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diagnostics-prometheus`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/memory-core`, `plugin-sdk/memory-lancedb`, `plugin-sdk/opencode`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Шви допоміжних засобів bundled features/Plugin; `plugin-sdk/github-copilot-token` наразі експортує `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` і `resolveCopilotApiToken` |
|
||||
| Допоміжні засоби для конкретних каналів | `plugin-sdk/googlechat`, `plugin-sdk/googlechat-runtime-shared`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu`, `plugin-sdk/feishu-conversation`, `plugin-sdk/feishu-setup`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/telegram-command-ui`, `plugin-sdk/tlon`, `plugin-sdk/twitch`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup` | Застарілі compatibility/helper seams bundled channel. Нові Plugin мають імпортувати універсальні підшляхи SDK або локальні barrel-файли Plugin. |
|
||||
| Допоміжні засоби для auth/plugin | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diagnostics-prometheus`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/memory-core`, `plugin-sdk/memory-lancedb`, `plugin-sdk/opencode`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Допоміжні seams для bundled feature/plugin; `plugin-sdk/github-copilot-token` наразі експортує `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` і `resolveCopilotApiToken` |
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
|
||||
@ -1,122 +1,125 @@
|
||||
---
|
||||
read_when:
|
||||
- Шукаю визначення публічних каналів релізу
|
||||
- Запуск валідації релізу або перевірки прийнятності пакета
|
||||
- Шукаю найменування версій і каденцію
|
||||
summary: Релізні лінії, контрольний список оператора, поля валідації, найменування версій і каденція
|
||||
title: Політика релізів
|
||||
- Запуск валідації релізу або приймання пакета
|
||||
- Шукаю іменування версій і каденс
|
||||
summary: Лейни релізу, контрольний список оператора, блоки валідації, іменування версій і каденс
|
||||
title: Політика релізу
|
||||
x-i18n:
|
||||
generated_at: "2026-04-27T19:39:05Z"
|
||||
generated_at: "2026-04-27T21:05:08Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 1ad73d75e54bd21cb740b64af0b33cc9d38283de8917544d5795990d3f0aacb6
|
||||
source_hash: f3ff3c7887c59005a977522e3a0e80ea3458e29d12f6976397b0749d8001d914
|
||||
source_path: reference/RELEASING.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
OpenClaw має три публічні лінії релізів:
|
||||
OpenClaw має три публічні лейни релізу:
|
||||
|
||||
- stable: теговані релізи, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано
|
||||
- beta: теги попередніх релізів, які публікуються в npm `beta`
|
||||
- dev: рухома вершина `main`
|
||||
- beta: теги передрелізів, які публікуються в npm `beta`
|
||||
- dev: рухома голова `main`
|
||||
|
||||
## Найменування версій
|
||||
## Іменування версій
|
||||
|
||||
- Версія стабільного релізу: `YYYY.M.D`
|
||||
- Версія stable-релізу: `YYYY.M.D`
|
||||
- Git-тег: `vYYYY.M.D`
|
||||
- Версія виправного стабільного релізу: `YYYY.M.D-N`
|
||||
- Версія коригувального stable-релізу: `YYYY.M.D-N`
|
||||
- Git-тег: `vYYYY.M.D-N`
|
||||
- Версія бета-попереднього релізу: `YYYY.M.D-beta.N`
|
||||
- Версія beta-передрелізу: `YYYY.M.D-beta.N`
|
||||
- Git-тег: `vYYYY.M.D-beta.N`
|
||||
- Не додавайте нулі на початку місяця або дня
|
||||
- `latest` означає поточний опублікований стабільний npm-реліз
|
||||
- `beta` означає поточну ціль інсталяції бета-версії
|
||||
- Стабільні та виправні стабільні релізи за замовчуванням публікуються в npm `beta`; оператори релізів можуть явно націлити `latest` або пізніше просунути перевірену бета-збірку
|
||||
- Кожен стабільний реліз OpenClaw постачається разом із npm-пакетом і застосунком для macOS;
|
||||
бета-релізи зазвичай спочатку проходять валідацію та публікацію шляху npm/package, а
|
||||
збірка/підпис/нотаризація застосунку для macOS зарезервовані для stable, якщо це не запитано явно
|
||||
- Не додавайте провідні нулі до місяця або дня
|
||||
- `latest` означає поточний просунутий stable-реліз npm
|
||||
- `beta` означає поточну ціль встановлення beta
|
||||
- Stable-релізи та коригувальні stable-релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або просунути перевірену beta-збірку пізніше
|
||||
- Кожен stable-реліз OpenClaw постачається разом із npm-пакетом і застосунком macOS;
|
||||
beta-релізи зазвичай спочатку проходять валідацію та публікацію шляху npm/package, а
|
||||
збірка/підпис/нотаризація застосунку macOS зарезервовані для stable, якщо явно не запитано
|
||||
|
||||
## Каденція релізів
|
||||
## Каденс релізів
|
||||
|
||||
- Релізи спочатку проходять через beta
|
||||
- Stable іде лише після того, як найновішу beta валідовано
|
||||
- Супровідники зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної
|
||||
- Релізи рухаються за схемою beta-first
|
||||
- Stable іде лише після валідації останньої beta
|
||||
- Мейнтейнери зазвичай роблять релізи з гілки `release/YYYY.M.D`, створеної
|
||||
з поточної `main`, щоб валідація релізу та виправлення не блокували нову
|
||||
розробку в `main`
|
||||
- Якщо beta-тег уже було запушено або опубліковано й потрібне виправлення, супровідники створюють
|
||||
наступний тег `-beta.N` замість видалення або перевідтворення старого beta-тега
|
||||
- Детальна процедура релізу, схвалення, облікові дані та примітки щодо відновлення
|
||||
доступні лише для супровідників
|
||||
- Якщо beta-тег уже було запушено або опубліковано й він потребує виправлення, мейнтейнери створюють
|
||||
наступний тег `-beta.N` замість видалення або повторного створення старого beta-тегу
|
||||
- Детальна процедура релізу, погодження, облікові дані та примітки щодо відновлення
|
||||
доступні лише мейнтейнерам
|
||||
|
||||
## Контрольний список оператора релізу
|
||||
|
||||
Цей контрольний список — публічна форма процесу релізу. Приватні облікові дані,
|
||||
Цей контрольний список — публічний контур процесу релізу. Приватні облікові дані,
|
||||
підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату
|
||||
залишаються в закритому для супровідників runbook релізів.
|
||||
залишаються в runbook релізу лише для мейнтейнерів.
|
||||
|
||||
1. Почніть із поточної `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт запушено,
|
||||
1. Почніть з поточної `main`: отримайте останні зміни, підтвердьте, що цільовий коміт запушено,
|
||||
і що поточний CI для `main` достатньо зелений, щоб відгалужуватися від нього.
|
||||
2. Перепишіть верхню секцію `CHANGELOG.md` на основі реальної історії комітів за допомогою
|
||||
`/changelog`, залишайте записи орієнтованими на користувача, закомітьте це, запуште
|
||||
і ще раз виконайте rebase/pull перед створенням гілки.
|
||||
`/changelog`, залишайте записи орієнтованими на користувача, закомітьте це, запуште і
|
||||
ще раз виконайте rebase/pull перед створенням гілки.
|
||||
3. Перегляньте записи сумісності релізу в
|
||||
`src/plugins/compat/registry.ts` і
|
||||
`src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
|
||||
сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її
|
||||
навмисно залишено.
|
||||
навмисно збережено.
|
||||
4. Створіть `release/YYYY.M.D` з поточної `main`; не виконуйте звичайну роботу з релізом
|
||||
безпосередньо в `main`.
|
||||
5. Оновіть усі необхідні місця з версією для запланованого тега, потім виконайте
|
||||
локальний детермінований попередній прогін:
|
||||
5. Оновіть кожне обов’язкове місце з версією для запланованого тегу, а потім виконайте
|
||||
локальний детермінований preflight:
|
||||
`pnpm check:test-types`, `pnpm check:architecture`,
|
||||
`pnpm build && pnpm ui:build` і `pnpm release:check`.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. Поки тега ще немає,
|
||||
`pnpm build && pnpm ui:build`, і `pnpm release:check`.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тегу
|
||||
для preflight лише з метою валідації дозволено повний 40-символьний SHA гілки релізу.
|
||||
Збережіть успішний `preflight_run_id`.
|
||||
7. Запустіть усі передрелізні тести через `Full Release Validation` для
|
||||
гілки релізу, тега або повного SHA коміту. Це єдина ручна точка входу
|
||||
для чотирьох великих полів тестування релізу: Vitest, Docker, QA Lab і Package.
|
||||
8. Якщо валідація не пройшла, виправте проблему в гілці релізу і перезапустіть найменший збоєвий
|
||||
файл, лінію, завдання workflow, профіль пакета, allowlist провайдера або моделі, який
|
||||
доводить виправлення. Повторно запускайте повний umbrella лише тоді, коли змінена поверхня
|
||||
гілки релізу, тегу або повного SHA коміту. Це єдина ручна точка входу
|
||||
для чотирьох великих блоків тестування релізу: Vitest, Docker, QA Lab і Package.
|
||||
8. Якщо валідація не пройшла, виправте проблему в гілці релізу і повторно запустіть найменший невдалий
|
||||
файл, лейн, завдання workflow, профіль пакета, allowlist провайдера або моделі, який
|
||||
підтверджує виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня
|
||||
робить попередні докази неактуальними.
|
||||
9. Для beta створіть тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, а потім запустіть
|
||||
post-publish package acceptance для опублікованого пакета `openclaw@YYYY.M.D-beta.N`
|
||||
або `openclaw@beta`. Якщо запушена або опублікована beta потребує виправлення, створюйте
|
||||
або `openclaw@beta`. Якщо запушена або опублікована beta потребує виправлення, створіть
|
||||
наступний `-beta.N`; не видаляйте і не переписуйте стару beta.
|
||||
10. Для stable продовжуйте лише після того, як перевірена beta або кандидат на реліз має
|
||||
потрібні докази валідації. Стабільна публікація в npm повторно використовує успішний
|
||||
preflight-артефакт через `preflight_run_id`; готовність stable-релізу для macOS
|
||||
10. Для stable продовжуйте лише після того, як перевірена beta або кандидат на реліз матиме
|
||||
необхідні докази валідації. Stable-публікація в npm повторно використовує успішний
|
||||
артефакт preflight через `preflight_run_id`; готовність stable-релізу для macOS
|
||||
також вимагає упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого
|
||||
`appcast.xml` у `main`.
|
||||
11. Після публікації запустіть верифікатор npm після публікації, за потреби —
|
||||
окремий Telegram E2E для опублікованого npm, коли вам потрібне підтвердження каналу після публікації,
|
||||
за потреби просування dist-tag, нотатки GitHub release/prerelease з
|
||||
11. Після публікації запустіть верифікатор npm після публікації, необов’язковий окремий
|
||||
Telegram E2E для опублікованого npm, коли потрібен доказ каналу після публікації,
|
||||
просування dist-tag за потреби, примітки GitHub release/prerelease з
|
||||
повної відповідної секції `CHANGELOG.md`, а також кроки
|
||||
анонсу релізу.
|
||||
оголошення релізу.
|
||||
|
||||
## Попередній прогін релізу
|
||||
## Preflight релізу
|
||||
|
||||
- Запускайте `pnpm check:test-types` перед попереднім прогоном релізу, щоб TypeScript для тестів
|
||||
залишався покритим поза межами швидшого локального бар’єра `pnpm check`
|
||||
- Запускайте `pnpm check:architecture` перед попереднім прогоном релізу, щоб ширші перевірки
|
||||
циклів імпорту та меж архітектури були зеленими поза межами швидшого локального бар’єра
|
||||
- Запускайте `pnpm check:test-types` перед release preflight, щоб TypeScript для тестів
|
||||
залишався покритим поза швидшим локальним gate `pnpm check`
|
||||
- Запускайте `pnpm check:architecture` перед release preflight, щоб ширші перевірки
|
||||
циклів імпорту та меж архітектури були зеленими поза швидшим локальним gate
|
||||
- Запускайте `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
|
||||
артефакти релізу `dist/*` і зібраний Control UI існували для кроку
|
||||
артефакти релізу `dist/*` і бандл Control UI існували для кроку
|
||||
валідації pack
|
||||
- Запускайте ручний workflow `Full Release Validation` перед схваленням релізу, щоб
|
||||
запустити всі передрелізні поля тестування з однієї точки входу. Він приймає гілку,
|
||||
тег або повний SHA коміту, викликає ручний `CI` і викликає
|
||||
- Запускайте ручний workflow `Full Release Validation` перед погодженням релізу, щоб
|
||||
запустити всі блоки передрелізного тестування з однієї точки входу. Він приймає гілку,
|
||||
тег або повний SHA коміту, викликає вручну `CI` і викликає
|
||||
`OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker
|
||||
шляху релізу, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram
|
||||
ліній. Вказуйте `npm_telegram_package_spec` лише після того, як пакет уже було
|
||||
опубліковано і також має запускатися Telegram E2E після публікації. Приклад:
|
||||
для шляху релізу, live/E2E, OpenWebUI, QA Lab parity, Matrix і лейнів
|
||||
Telegram. Вказуйте `npm_telegram_package_spec` лише після того, як пакет уже
|
||||
опубліковано і також має виконуватися Telegram E2E після публікації. Вказуйте
|
||||
`evidence_package_spec`, коли приватний звіт доказів має підтверджувати, що
|
||||
валідація відповідає опублікованому npm-пакету без примусового запуску Telegram E2E.
|
||||
Приклад:
|
||||
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
|
||||
- Запускайте ручний workflow `Package Acceptance`, коли вам потрібне додаткове підтвердження
|
||||
для кандидата пакета, поки триває робота над релізом. Використовуйте `source=npm` для
|
||||
- Запускайте ручний workflow `Package Acceptance`, коли потрібен побічний доказ
|
||||
для кандидата пакета, поки робота над релізом триває. Використовуйте `source=npm` для
|
||||
`openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`,
|
||||
щоб запакувати довірену гілку/тег/SHA `package_ref` з поточною
|
||||
обв’язкою `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
|
||||
щоб упакувати довірену гілку/тег/SHA `package_ref` з поточним harness
|
||||
`workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
|
||||
SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub
|
||||
Actions. Workflow визначає кандидата як
|
||||
`package-under-test`, повторно використовує планувальник Docker E2E шляху релізу для цього
|
||||
@ -124,148 +127,149 @@ OpenClaw має три публічні лінії релізів:
|
||||
`telegram_mode=mock-openai` або `telegram_mode=live-frontier`.
|
||||
Приклад: `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 telegram_mode=mock-openai`
|
||||
Поширені профілі:
|
||||
- `smoke`: лінії install/channel/agent, мережі gateway і перезавантаження конфігурації
|
||||
- `package`: нативні для артефакта лінії пакета/оновлення/Plugin без OpenWebUI або live ClawHub
|
||||
- `smoke`: лейни install/channel/agent, мережі Gateway і перезавантаження конфігурації
|
||||
- `package`: артефактно-нативні лейни пакета/оновлення/Plugin без OpenWebUI або live ClawHub
|
||||
- `product`: профіль package плюс канали MCP, очищення cron/subagent,
|
||||
вебпошук OpenAI і OpenWebUI
|
||||
- `full`: частини Docker шляху релізу з OpenWebUI
|
||||
- `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
|
||||
- Запускайте ручний workflow `CI` безпосередньо, коли вам потрібне лише повне нормальне
|
||||
покриття CI для кандидата релізу. Ручний виклик CI обходить обмеження changed
|
||||
і примусово запускає Linux Node shards, bundled-plugin shards, channel
|
||||
contracts, сумісність з Node 22, `check`, `check-additional`, build smoke,
|
||||
перевірки документації, Python Skills, Windows, macOS, Android і лінії i18n для Control UI.
|
||||
- `full`: частини Docker release-path з OpenWebUI
|
||||
- `custom`: точний вибір `docker_lanes` для цільового повторного запуску
|
||||
- Запускайте ручний workflow `CI` безпосередньо, коли потрібне лише повне звичайне покриття
|
||||
CI для кандидата на реліз. Ручний запуск CI оминає changed scoping і примусово запускає
|
||||
Linux Node shards, shards bundled-plugin, контракти каналів, сумісність Node 22, `check`,
|
||||
`check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS, Android і
|
||||
лейни i18n для Control UI.
|
||||
Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
|
||||
- Запускайте `pnpm qa:otel:smoke` під час валідації телеметрії релізу. Це проганяє
|
||||
QA-lab через локальний приймач OTLP/HTTP і перевіряє експортовані назви trace span,
|
||||
обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в
|
||||
Opik, Langfuse або іншому зовнішньому збирачі.
|
||||
Opik, Langfuse або іншому зовнішньому collector.
|
||||
- Запускайте `pnpm release:check` перед кожним тегованим релізом
|
||||
- Перевірки релізу тепер виконуються в окремому ручному workflow:
|
||||
`OpenClaw Release Checks`
|
||||
- `OpenClaw Release Checks` також запускає QA Lab mock parity gate і швидкий
|
||||
live Matrix profile та лінію Telegram QA перед схваленням релізу. Live
|
||||
лінії використовують середовище `qa-live-shared`; Telegram також використовує оренду
|
||||
облікових даних Convex CI. Запускайте ручний workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли вам потрібен повний інвентар
|
||||
Matrix transport, media та E2EE паралельно.
|
||||
- Крос-ОС валідація install і upgrade під час виконання є частиною публічних
|
||||
- `OpenClaw Release Checks` також запускає QA Lab mock parity gate разом із швидким
|
||||
live-профілем Matrix і лейном Telegram QA перед погодженням релізу. Live-лейни використовують
|
||||
середовище `qa-live-shared`; Telegram також використовує оренду облікових даних Convex CI.
|
||||
Запускайте ручний workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли потрібен повний паралельний інвентар
|
||||
транспорту, медіа та E2EE Matrix.
|
||||
- Крос-ОС валідація встановлення та оновлення під час виконання є частиною публічних
|
||||
`OpenClaw Release Checks` і `Full Release Validation`, які викликають
|
||||
повторно використовуваний workflow
|
||||
reusable workflow
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml` безпосередньо
|
||||
- Такий поділ навмисний: реальний шлях npm-релізу має залишатися коротким,
|
||||
- Цей поділ навмисний: зберігайте справжній шлях npm-релізу коротким,
|
||||
детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються
|
||||
у власній лінії, щоб не затримувати і не блокувати публікацію
|
||||
у власному лейні, щоб не затримувати й не блокувати публікацію
|
||||
- Перевірки релізу, що використовують секрети, слід запускати через `Full Release
|
||||
Validation` або з workflow ref `main`/release, щоб логіка workflow і
|
||||
секрети залишалися контрольованими
|
||||
- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо
|
||||
визначений коміт досяжний з гілки OpenClaw або тега релізу
|
||||
- Попередній прогін `OpenClaw NPM Release` лише для валідації також приймає поточний
|
||||
повний 40-символьний SHA коміту гілки workflow без вимоги запушеного тега
|
||||
- Цей шлях із SHA призначений лише для валідації й не може бути просунутий до реальної публікації
|
||||
- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
|
||||
метаданих пакета; реальна публікація все одно вимагає реального тега релізу
|
||||
- Обидва workflows зберігають реальний шлях публікації та просування на GitHub-hosted
|
||||
runners, тоді як незмінний шлях валідації може використовувати більші
|
||||
- Валідаційний preflight `OpenClaw NPM Release` також приймає поточний
|
||||
повний 40-символьний SHA коміту гілки workflow без вимоги запушеного тегу
|
||||
- Цей шлях із SHA призначений лише для валідації і не може бути підвищений до справжньої публікації
|
||||
- У режимі SHA workflow синтезує `v<package.json version>` лише для
|
||||
перевірки метаданих пакета; справжня публікація все одно вимагає реального тега релізу
|
||||
- Обидва workflows залишають справжній шлях публікації та просування на GitHub-hosted
|
||||
runners, тоді як немутуючий шлях валідації може використовувати більші
|
||||
Blacksmith Linux runners
|
||||
- Цей workflow запускає
|
||||
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
|
||||
з використанням обох секретів workflow `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
|
||||
- Попередній прогін npm release більше не чекає на окрему лінію release checks
|
||||
з використанням обох workflow secrets: `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
|
||||
- npm release preflight більше не чекає на окремий лейн перевірок релізу
|
||||
- Запускайте `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(або відповідний beta/correction тег) перед схваленням
|
||||
(або відповідний beta/correction тег) перед погодженням
|
||||
- Після публікації в npm запускайте
|
||||
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
|
||||
(або відповідну beta/correction версію), щоб перевірити шлях інсталяції
|
||||
з опублікованого реєстру в чистому тимчасовому prefix
|
||||
(або відповідну beta/correction версію), щоб перевірити шлях встановлення з
|
||||
опублікованого реєстру в новому тимчасовому префіксі
|
||||
- Після публікації beta запускайте `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. Для разових локальних запусків супровідники можуть не вказувати змінні Convex
|
||||
і передавати три облікові дані через env `OPENCLAW_QA_TELEGRAM_*` безпосередньо.
|
||||
- Супровідники можуть запускати ту саму перевірку після публікації з GitHub Actions через
|
||||
ручний workflow `NPM Telegram Beta E2E`. Він навмисно є лише ручним
|
||||
і не запускається після кожного merge.
|
||||
- Автоматизація релізів супровідників тепер використовує preflight-then-promote:
|
||||
- реальна публікація в npm має пройти успішний npm `preflight_run_id`
|
||||
- реальна публікація в npm має запускатися з тієї самої гілки `main` або
|
||||
щоб перевірити onboarding встановленого пакета, налаштування Telegram і справжній Telegram E2E
|
||||
проти опублікованого npm-пакета, використовуючи спільний пул орендованих облікових даних Telegram.
|
||||
Для локальних одноразових перевірок мейнтейнера можна не вказувати змінні Convex і передати
|
||||
безпосередньо три env-облікові дані `OPENCLAW_QA_TELEGRAM_*`.
|
||||
- Мейнтейнери можуть запускати ту саму перевірку після публікації через GitHub Actions за допомогою
|
||||
ручного workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
|
||||
не запускається після кожного merge.
|
||||
- Автоматизація релізів мейнтейнера тепер використовує схему preflight-then-promote:
|
||||
- справжня публікація в npm має пройти успішний npm `preflight_run_id`
|
||||
- справжню публікацію в npm слід запускати з тієї самої гілки `main` або
|
||||
`release/YYYY.M.D`, що й успішний запуск preflight
|
||||
- стабільні npm-релізи за замовчуванням спрямовані в `beta`
|
||||
- стабільна публікація в npm може явно націлювати `latest` через input workflow
|
||||
- зміна npm dist-tag на основі токена тепер розміщена в
|
||||
- stable npm-релізи за замовчуванням використовують `beta`
|
||||
- stable-публікація в npm може явно націлюватися на `latest` через вхідні дані workflow
|
||||
- мутація npm dist-tag на основі токена тепер знаходиться в
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
|
||||
з міркувань безпеки, тому що `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
|
||||
з міркувань безпеки, оскільки `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
|
||||
публічний репозиторій зберігає публікацію лише через OIDC
|
||||
- публічний `macOS Release` призначений лише для валідації
|
||||
- реальна приватна публікація для mac має пройти успішні приватні
|
||||
`preflight_run_id` і `validate_run_id`
|
||||
- реальні шляхи публікації просувають підготовлені артефакти замість їх повторної збірки
|
||||
- Для виправних стабільних релізів на кшталт `YYYY.M.D-N` верифікатор після публікації
|
||||
також перевіряє той самий шлях оновлення в тимчасовому prefix з `YYYY.M.D` до `YYYY.M.D-N`,
|
||||
щоб виправні релізи не могли непомітно залишати старі глобальні інсталяції на
|
||||
базовому стабільному payload
|
||||
- Попередній прогін npm release завершується з відмовою за замовчуванням, якщо tarball не містить
|
||||
і `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
|
||||
щоб ми знову не випустили порожню панель браузера
|
||||
- Перевірка після публікації також перевіряє, що інсталяція з опублікованого реєстру
|
||||
містить непорожні runtime-залежності bundled Plugin у кореневому макеті
|
||||
`dist/*`. Реліз, який постачається з відсутніми або порожніми payload залежностей
|
||||
bundled Plugin, не проходить postpublish verifier і не може бути просунутий
|
||||
- справжня приватна публікація mac має пройти успішні приватні `preflight_run_id`
|
||||
і `validate_run_id` для mac
|
||||
- справжні шляхи публікації просувають підготовлені артефакти замість їх повторного збирання
|
||||
- Для коригувальних stable-релізів на кшталт `YYYY.M.D-N` верифікатор після публікації
|
||||
також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`,
|
||||
щоб корекції релізу не могли непомітно залишити старі глобальні встановлення на
|
||||
базовому stable-навантаженні
|
||||
- npm release preflight завершується із закритою помилкою, якщо tarball не містить і `dist/control-ui/index.html`,
|
||||
і непорожнє навантаження `dist/control-ui/assets/`, щоб ми знову не
|
||||
випустили порожню браузерну панель керування
|
||||
- Перевірка після публікації також перевіряє, що встановлення з опублікованого реєстру
|
||||
містить непорожні runtime-залежності bundled Plugin у кореневому
|
||||
макеті `dist/*`. Реліз, який постачається з відсутнім або порожнім навантаженням
|
||||
залежностей bundled Plugin, не проходить верифікатор після публікації і не може бути просунутий
|
||||
до `latest`.
|
||||
- `pnpm test:install:smoke` також застосовує бюджет `unpackedSize` для `npm pack`
|
||||
до tarball кандидата на оновлення, тому installer e2e виявляє випадкове роздуття pack
|
||||
до шляху публікації релізу
|
||||
- Якщо робота над релізом зачепила планування CI, маніфести часу розширень або
|
||||
матриці тестів розширень, перед схваленням заново згенеруйте й перегляньте
|
||||
матричні результати workflow `checks-node-extensions`, якими володіє planner, з `.github/workflows/ci.yml`,
|
||||
щоб примітки до релізу не описували застарілу структуру CI
|
||||
- Готовність stable-релізу для macOS також включає поверхні оновлювача:
|
||||
- GitHub release має врешті містити упаковані `.zip`, `.dmg` і `.dSYM.zip`
|
||||
- `pnpm test:install:smoke` також примусово перевіряє бюджет `unpackedSize` для npm pack
|
||||
у tarball кандидата на оновлення, щоб installer e2e виявляв випадкове збільшення
|
||||
пакета до шляху публікації релізу
|
||||
- Якщо робота над релізом торкалася планування CI, маніфестів часу extension або
|
||||
матриць тестів extension, перед погодженням заново згенеруйте й перегляньте
|
||||
матричні виводи `checks-node-extensions`, якими володіє planner, з `.github/workflows/ci.yml`,
|
||||
щоб примітки до релізу не описували застарілу схему CI
|
||||
- Готовність stable-релізу macOS також включає поверхні оновлювача:
|
||||
- GitHub release має зрештою містити упаковані `.zip`, `.dmg` і `.dSYM.zip`
|
||||
- `appcast.xml` у `main` має вказувати на новий stable zip після публікації
|
||||
- упакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed
|
||||
URL і `CFBundleVersion` на рівні або вище канонічного мінімального Sparkle build
|
||||
- упакований застосунок має зберігати non-debug bundle id, непорожню
|
||||
Sparkle feed URL і `CFBundleVersion` на рівні або вище канонічного мінімального build-рівня Sparkle
|
||||
для цієї версії релізу
|
||||
|
||||
## Поля тестування релізу
|
||||
## Блоки тестування релізу
|
||||
|
||||
`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з
|
||||
однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте гілку релізу,
|
||||
тег або повний SHA коміту як `ref`:
|
||||
`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести
|
||||
з однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте
|
||||
гілку релізу, тег або повний SHA коміту як `ref`:
|
||||
|
||||
```bash
|
||||
gh workflow run full-release-validation.yml \
|
||||
--ref main \
|
||||
-f ref=release/YYYY.M.D \
|
||||
-f provider=openai \
|
||||
-f mode=both
|
||||
-f mode=both \
|
||||
-f evidence_package_spec=openclaw@YYYY.M.D-beta.N
|
||||
```
|
||||
|
||||
Workflow визначає цільовий ref, викликає ручний `CI` з
|
||||
Workflow визначає цільовий ref, викликає вручну `CI` з
|
||||
`target_ref=<release-ref>`, викликає `OpenClaw Release Checks` і
|
||||
за потреби викликає окремий Telegram E2E після публікації, коли
|
||||
встановлено `npm_telegram_package_spec`. Потім `OpenClaw Release Checks` розгалужує
|
||||
install smoke, крос-ОС release checks, live/E2E покриття Docker шляху релізу,
|
||||
Package Acceptance з Telegram QA для пакета, QA Lab parity, live Matrix і
|
||||
live Telegram. Повний запуск прийнятний лише тоді, коли підсумок `Full Release Validation`
|
||||
показує `normal_ci` і `release_checks` як успішні, а будь-який необов’язковий дочірній
|
||||
встановлено `npm_telegram_package_spec`. Далі `OpenClaw Release Checks` розгалужує
|
||||
install smoke, крос-ОС перевірки релізу, live/E2E покриття Docker release-path,
|
||||
Package Acceptance із Telegram package QA, QA Lab parity, live Matrix і
|
||||
live Telegram. Повний запуск є прийнятним лише тоді, коли у підсумку `Full Release Validation`
|
||||
показано `normal_ci` і `release_checks` як успішні, а будь-який необов’язковий дочірній
|
||||
`npm_telegram` або успішний, або навмисно пропущений.
|
||||
Дочірні workflows викликаються з довіреного ref, який запускає `Full Release
|
||||
Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на старішу
|
||||
гілку або тег релізу. Окремого input workflow-ref для Full Release Validation
|
||||
немає; вибирайте довірену обв’язку, вибираючи ref запуску workflow.
|
||||
Дочірні workflows викликаються з довіреного ref, що запускає `Full Release
|
||||
Validation`, зазвичай `--ref main`, навіть якщо цільовий `ref` вказує на
|
||||
старішу гілку релізу або тег. Окремого входу workflow-ref для Full Release Validation
|
||||
немає; вибирайте довірений harness, вибираючи ref запуску workflow.
|
||||
|
||||
Використовуйте ці варіанти залежно від етапу релізу:
|
||||
|
||||
```bash
|
||||
# Валідовувати неопубліковану гілку кандидата релізу.
|
||||
# Валідувати неопубліковану гілку кандидата на реліз.
|
||||
gh workflow run full-release-validation.yml \
|
||||
--ref main \
|
||||
-f ref=release/YYYY.M.D \
|
||||
-f provider=openai \
|
||||
-f mode=both
|
||||
|
||||
# Валідовувати точний запушений коміт.
|
||||
# Валідувати точний запушений коміт.
|
||||
gh workflow run full-release-validation.yml \
|
||||
--ref main \
|
||||
-f ref=<40-char-sha> \
|
||||
@ -278,38 +282,38 @@ gh workflow run full-release-validation.yml \
|
||||
-f ref=release/YYYY.M.D \
|
||||
-f provider=openai \
|
||||
-f mode=both \
|
||||
-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
|
||||
```
|
||||
|
||||
Не використовуйте повний umbrella як перший повторний запуск після точкового виправлення. Якщо одне поле
|
||||
не проходить, використовуйте збійний дочірній workflow, job, Docker lane, профіль
|
||||
пакета, провайдера моделі або QA lane для наступного підтвердження. Повторно запускайте повний
|
||||
umbrella лише тоді, коли виправлення змінило спільну оркестрацію релізу або
|
||||
зробило попередні докази для всіх полів неактуальними. Фінальний верифікатор umbrella
|
||||
повторно перевіряє записані run id дочірніх workflows, тому після успішного повторного запуску
|
||||
дочірнього workflow повторно запускайте лише збійний батьківський job
|
||||
`Verify full validation`.
|
||||
Не використовуйте повну парасольку як перший повторний запуск після точкового виправлення. Якщо один блок
|
||||
не пройшов, використовуйте невдалий дочірній workflow, job, Docker lane, профіль пакета, модель
|
||||
провайдера або QA-лейн для наступного підтвердження. Повторно запускайте повну парасольку лише тоді, коли
|
||||
виправлення змінило спільну оркестрацію релізу або зробило попередні докази для всіх блоків
|
||||
неактуальними. Фінальний верифікатор парасольки повторно перевіряє записані run id дочірніх workflow,
|
||||
тож після успішного повторного запуску дочірнього workflow повторно запускайте лише
|
||||
невдалий батьківський job `Verify full validation`.
|
||||
|
||||
### Vitest
|
||||
|
||||
Поле Vitest — це дочірній workflow ручного `CI`. Ручний CI навмисно
|
||||
обходить обмеження changed і примусово запускає звичайний граф тестів для
|
||||
кандидата релізу: Linux Node shards, bundled-plugin shards, channel contracts, сумісність з Node 22,
|
||||
`check`, `check-additional`, build smoke, перевірки документації, Python
|
||||
Блок Vitest — це дочірній ручний workflow `CI`. Ручний CI навмисно
|
||||
оминає changed scoping і примусово запускає звичайний тестовий граф для
|
||||
кандидата на реліз: Linux Node shards, bundled-plugin shards, channel contracts, Node 22
|
||||
compatibility, `check`, `check-additional`, build smoke, docs checks, Python
|
||||
Skills, Windows, macOS, Android і i18n для Control UI.
|
||||
|
||||
Використовуйте це поле, щоб відповісти на запитання «чи пройшло дерево вихідного коду повний звичайний набір тестів?»
|
||||
Використовуйте цей блок, щоб відповісти на запитання «чи пройшло дерево вихідного коду повний звичайний набір тестів?»
|
||||
Це не те саме, що валідація продукту на шляху релізу. Докази, які слід зберігати:
|
||||
|
||||
- Підсумок `Full Release Validation`, що показує URL запущеного `CI`
|
||||
- Зелений запуск `CI` на точному цільовому SHA
|
||||
- Назви збійних або повільних shard із job `CI` під час розслідування регресій
|
||||
- Артефакти таймінгів Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли
|
||||
- підсумок `Full Release Validation`, що показує URL запущеного прогону `CI`
|
||||
- зелений прогін `CI` на точному цільовому SHA
|
||||
- назви shard-ів, що впали або працювали повільно, із job-ів CI під час дослідження регресій
|
||||
- артефакти часу Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли
|
||||
запуск потребує аналізу продуктивності
|
||||
|
||||
Запускайте ручний CI безпосередньо лише тоді, коли релізу потрібен детермінований звичайний CI, але
|
||||
не Docker, QA Lab, live, крос-ОС або package поля:
|
||||
не потрібні блоки Docker, QA Lab, live, cross-OS або Package:
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
@ -317,94 +321,94 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
|
||||
### Docker
|
||||
|
||||
Поле Docker розміщене в `OpenClaw Release Checks` через
|
||||
Блок Docker знаходиться в `OpenClaw Release Checks` через
|
||||
`openclaw-live-and-e2e-checks-reusable.yml`, а також через workflow
|
||||
`install-smoke` у режимі релізу. Воно валідовує кандидата релізу через упаковані
|
||||
Docker-середовища, а не лише через тести на рівні вихідного коду.
|
||||
`install-smoke` у режимі релізу. Він валідовує кандидата на реліз через упаковані
|
||||
середовища Docker, а не лише через тести на рівні вихідного коду.
|
||||
|
||||
Покриття Docker для релізу включає:
|
||||
|
||||
- повний install smoke з увімкненим повільним Bun global install smoke
|
||||
- репозиторні E2E-лінії
|
||||
- Docker-частини шляху релізу: `core`, `package-update-openai`,
|
||||
- повний install smoke з увімкненим повільним smoke глобального встановлення Bun
|
||||
- лейни E2E для репозиторію
|
||||
- частини Docker для шляху релізу: `core`, `package-update-openai`,
|
||||
`package-update-anthropic`, `package-update-core`, `plugins-runtime-core`,
|
||||
`plugins-runtime-install-a`, `plugins-runtime-install-b` і
|
||||
`bundled-channels`
|
||||
- покриття OpenWebUI всередині частини `plugins-runtime-core`, якщо це запитано
|
||||
- розділені лінії залежностей bundled-channel у власній частині `bundled-channels`
|
||||
замість послідовної all-in-one bundled-channel лінії
|
||||
- розділені лінії встановлення/видалення bundled Plugin
|
||||
- покриття OpenWebUI всередині частини `plugins-runtime-core`, коли це запитано
|
||||
- розділені лейни залежностей bundled-channel у власній частині `bundled-channels`
|
||||
замість послідовного all-in-one лейна bundled-channel
|
||||
- розділені лейни встановлення/видалення bundled Plugin
|
||||
`bundled-plugin-install-uninstall-0` до
|
||||
`bundled-plugin-install-uninstall-7`
|
||||
- набори live/E2E для провайдерів і покриття live-моделей Docker, коли release checks
|
||||
- live/E2E набори провайдерів і покриття live-моделей Docker, коли перевірки релізу
|
||||
включають live-набори
|
||||
|
||||
Використовуйте артефакти Docker перед повторним запуском. Планувальник шляху релізу
|
||||
вивантажує `.artifacts/docker-tests/` з журналами ліній, `summary.json`, `failures.json`,
|
||||
таймінгами фаз, JSON плану планувальника і командами повторного запуску. Для точкового відновлення
|
||||
використовуйте `docker_lanes=<lane[,lane]>` у повторно використовуваному workflow live/E2E замість
|
||||
повторного запуску всіх частин релізу. Згенеровані команди повторного запуску включають попередні
|
||||
`package_artifact_run_id` і підготовлені input образів Docker, коли вони доступні, тому
|
||||
збійна лінія може повторно використати той самий tarball і образи GHCR.
|
||||
вивантажує `.artifacts/docker-tests/` з логами лейнів, `summary.json`, `failures.json`,
|
||||
часом фаз, JSON плану планувальника та командами повторного запуску. Для точкового відновлення
|
||||
використовуйте `docker_lanes=<lane[,lane]>` у reusable workflow live/E2E замість
|
||||
повторного запуску всіх частин релізу. Згенеровані команди повторного запуску включають попередній
|
||||
`package_artifact_run_id` і підготовлені вхідні дані образів Docker, коли вони доступні, щоб
|
||||
лейн, що впав, міг повторно використати той самий tarball і образи GHCR.
|
||||
|
||||
### QA Lab
|
||||
|
||||
Поле QA Lab також є частиною `OpenClaw Release Checks`. Це релізний бар’єр для
|
||||
агентної поведінки та рівня каналів, окремий від механіки пакетів Vitest і Docker.
|
||||
Блок QA Lab також є частиною `OpenClaw Release Checks`. Це gate
|
||||
агентної поведінки та поведінки на рівні каналів для релізу, окремий від механіки пакетів Vitest і Docker.
|
||||
|
||||
Покриття QA Lab для релізу включає:
|
||||
|
||||
- mock parity gate, який порівнює лінію кандидата OpenAI з базовим рівнем Opus 4.6
|
||||
за допомогою agentic parity pack
|
||||
- швидкий live Matrix QA profile із середовищем `qa-live-shared`
|
||||
- live Telegram QA lane з орендою облікових даних Convex CI
|
||||
- mock parity gate, що порівнює кандидатний лейн OpenAI з базовим рівнем Opus 4.6
|
||||
за допомогою пакета agentic parity
|
||||
- швидкий live-профіль Matrix QA з використанням середовища `qa-live-shared`
|
||||
- live-лейн Telegram QA з орендою облікових даних Convex CI
|
||||
- `pnpm qa:otel:smoke`, коли телеметрія релізу потребує явного локального підтвердження
|
||||
|
||||
Використовуйте це поле, щоб відповісти на запитання «чи правильно поводиться реліз у QA-сценаріях і
|
||||
live-потоках каналів?» Під час схвалення релізу зберігайте URL артефактів для ліній parity, Matrix і Telegram.
|
||||
Повне покриття Matrix залишається доступним як ручний шардований запуск QA-Lab, а не як
|
||||
типова критична для релізу лінія.
|
||||
Використовуйте цей блок, щоб відповісти на запитання «чи правильно поводиться реліз у QA-сценаріях і
|
||||
live-потоках каналів?» Під час погодження релізу зберігайте URL артефактів для лейнів parity, Matrix і Telegram.
|
||||
Повне покриття Matrix залишається доступним як ручний шардований запуск QA-Lab, а не
|
||||
як типовий критичний для релізу лейн.
|
||||
|
||||
### Package
|
||||
|
||||
Поле Package — це бар’єр для продукту, який можна інсталювати. Воно базується на
|
||||
`Package Acceptance` і резолвері
|
||||
`scripts/resolve-openclaw-package-candidate.mjs`. Резолвер нормалізує
|
||||
Блок Package — це gate для встановлюваного продукту. Його підтримують
|
||||
`Package Acceptance` і resolver
|
||||
`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
|
||||
кандидата в tarball `package-under-test`, який споживає Docker E2E, валідовує
|
||||
інвентар пакета, записує версію пакета і SHA-256 та зберігає
|
||||
ref обв’язки workflow окремо від ref джерела пакета.
|
||||
ref harness workflow окремо від ref джерела пакета.
|
||||
|
||||
Підтримувані джерела кандидатів:
|
||||
Підтримувані джерела кандидата:
|
||||
|
||||
- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна версія релізу OpenClaw
|
||||
- `source=ref`: запакувати довірену гілку, тег або повний SHA коміту `package_ref`
|
||||
з вибраною обв’язкою `workflow_ref`
|
||||
- `source=ref`: упакувати довірену гілку, тег або повний SHA коміту `package_ref`
|
||||
з вибраним harness `workflow_ref`
|
||||
- `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256`
|
||||
- `source=artifact`: повторно використати `.tgz`, вивантажений іншим запуском GitHub Actions
|
||||
|
||||
`OpenClaw Release Checks` запускає Package Acceptance з `source=ref`,
|
||||
`package_ref=<release-ref>`, `suite_profile=custom`,
|
||||
`docker_lanes=bundled-channel-deps-compat plugins-offline` і
|
||||
`telegram_mode=mock-openai`. Docker-частини шляху релізу покривають
|
||||
лінії install, update і plugin-update, що перетинаються; Package Acceptance зберігає
|
||||
нативну для артефактів сумісність bundled-channel, офлайн-фікстури Plugin і Telegram
|
||||
`telegram_mode=mock-openai`. Частини Docker для шляху релізу покривають
|
||||
лейни встановлення, оновлення та оновлення Plugin, що перетинаються; Package Acceptance
|
||||
зберігає артефактно-нативну сумісність bundled-channel, офлайн-фікстури Plugin і Telegram
|
||||
package QA проти того самого визначеного tarball. Це GitHub-native
|
||||
заміна для більшості покриття package/update, яке раніше вимагало
|
||||
Parallels. Крос-ОС release checks усе ще важливі для специфічної для ОС адаптації,
|
||||
інсталятора та поведінки платформи, але для валідації package/update продукту слід
|
||||
надавати перевагу Package Acceptance.
|
||||
Parallels. Cross-OS перевірки релізу все ще важливі для специфічної для ОС поведінки onboarding,
|
||||
інсталятора та платформи, але валідація продукту package/update має
|
||||
віддавати перевагу Package Acceptance.
|
||||
|
||||
Історична поблажливість package-acceptance навмисно обмежена в часі. Пакети до
|
||||
`2026.4.25` можуть використовувати шлях сумісності для прогалин у метаданих, уже опублікованих
|
||||
в npm: приватні записи інвентарю QA, відсутні в tarball, відсутній
|
||||
`gateway install --wrapper`, відсутні patch-файли у git-фікстурі, похідній від tarball,
|
||||
відсутній збережений `update.channel`, застарілі розташування записів встановлення Plugin,
|
||||
відсутність збереження записів встановлення marketplace і міграція метаданих конфігурації під час
|
||||
`plugins update`. Пакети після `2026.4.25` повинні відповідати сучасним контрактам пакета;
|
||||
у npm: приватні записи інвентарю QA, відсутні в tarball; відсутній
|
||||
`gateway install --wrapper`; відсутні patch-файли у git-фікстурі, похідній від tarball;
|
||||
відсутній збережений `update.channel`; історичні розташування install-record для Plugin;
|
||||
відсутнє збереження install-record marketplace; і міграція метаданих конфігурації під час `plugins update`.
|
||||
Пакети після `2026.4.25` мають відповідати сучасним контрактам пакета;
|
||||
ті самі прогалини призводять до провалу валідації релізу.
|
||||
|
||||
Використовуйте ширші профілі Package Acceptance, коли питання релізу стосується
|
||||
реального пакета, який можна встановити:
|
||||
реального встановлюваного пакета:
|
||||
|
||||
```bash
|
||||
gh workflow run package-acceptance.yml \
|
||||
@ -417,43 +421,43 @@ gh workflow run package-acceptance.yml \
|
||||
|
||||
Поширені профілі пакета:
|
||||
|
||||
- `smoke`: швидкі лінії інсталяції package/channel/agent, мережі gateway і
|
||||
- `smoke`: швидкі лейни package install/channel/agent, мережі Gateway і
|
||||
перезавантаження конфігурації
|
||||
- `package`: контракти package для install/update/plugin без live ClawHub; це типовий варіант для release-check
|
||||
- `package`: контракти package install/update/plugin без live ClawHub; це типовий варіант release-check
|
||||
- `product`: `package` плюс канали MCP, очищення cron/subagent, вебпошук OpenAI
|
||||
і OpenWebUI
|
||||
- `full`: Docker-частини шляху релізу з OpenWebUI
|
||||
- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
|
||||
- `full`: частини Docker шляху релізу з OpenWebUI
|
||||
- `custom`: точний список `docker_lanes` для точкових повторних запусків
|
||||
|
||||
Для Telegram-підтвердження кандидата пакета увімкніть `telegram_mode=mock-openai` або
|
||||
Для доказу Telegram для кандидата пакета вмикайте `telegram_mode=mock-openai` або
|
||||
`telegram_mode=live-frontier` у Package Acceptance. Workflow передає
|
||||
визначений tarball `package-under-test` у Telegram lane; окремий
|
||||
workflow Telegram, як і раніше, приймає опубліковану npm-специфікацію для перевірок після публікації.
|
||||
визначений tarball `package-under-test` у лейн Telegram; окремий
|
||||
workflow Telegram як і раніше приймає специфікацію опублікованого npm для перевірок після публікації.
|
||||
|
||||
## Вхідні параметри workflow npm
|
||||
|
||||
`OpenClaw NPM Release` приймає такі керовані оператором input:
|
||||
`OpenClaw NPM Release` приймає такі вхідні параметри, контрольовані оператором:
|
||||
|
||||
- `tag`: обов’язковий тег релізу, такий як `v2026.4.2`, `v2026.4.2-1` або
|
||||
- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або
|
||||
`v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
|
||||
повний 40-символьний SHA коміту гілки workflow для preflight лише з валідацією
|
||||
- `preflight_only`: `true` лише для валідації/збірки/пакета, `false` для
|
||||
повний 40-символьний SHA коміту гілки workflow для preflight лише з метою валідації
|
||||
- `preflight_only`: `true` лише для валідації/збирання/пакета, `false` для
|
||||
реального шляху публікації
|
||||
- `preflight_run_id`: обов’язковий у реальному шляху публікації, щоб workflow повторно використовував
|
||||
- `preflight_run_id`: обов’язковий у реальному шляху публікації, щоб workflow повторно використав
|
||||
підготовлений tarball з успішного запуску preflight
|
||||
- `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta`
|
||||
|
||||
`OpenClaw Release Checks` приймає такі керовані оператором input:
|
||||
`OpenClaw Release Checks` приймає такі вхідні параметри, контрольовані оператором:
|
||||
|
||||
- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки, що використовують секрети,
|
||||
вимагають, щоб визначений коміт був досяжним із гілки OpenClaw або
|
||||
вимагають, щоб визначений коміт був досяжний з гілки OpenClaw або
|
||||
тега релізу.
|
||||
|
||||
Правила:
|
||||
|
||||
- Теги stable і correction можуть публікуватися або в `beta`, або в `latest`
|
||||
- Теги beta prerelease можуть публікуватися лише в `beta`
|
||||
- Для `OpenClaw NPM Release` input у вигляді повного SHA коміту дозволений лише коли
|
||||
- Stable- і correction-теги можуть публікуватися або в `beta`, або в `latest`
|
||||
- Beta prerelease-теги можуть публікуватися лише в `beta`
|
||||
- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволено лише коли
|
||||
`preflight_only=true`
|
||||
- `OpenClaw Release Checks` і `Full Release Validation` завжди
|
||||
призначені лише для валідації
|
||||
@ -462,39 +466,39 @@ workflow Telegram, як і раніше, приймає опубліковану
|
||||
|
||||
## Послідовність stable npm-релізу
|
||||
|
||||
Під час створення stable npm-релізу:
|
||||
Під час випуску stable npm-релізу:
|
||||
|
||||
1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
|
||||
- Поки тега ще немає, ви можете використовувати поточний повний SHA коміту гілки workflow
|
||||
для dry run workflow preflight лише з валідацією
|
||||
2. Виберіть `npm_dist_tag=beta` для звичайного beta-first процесу або `latest` лише
|
||||
коли ви навмисно хочете прямої stable-публікації
|
||||
3. Запустіть `Full Release Validation` на гілці релізу, тегу релізу або повному
|
||||
SHA коміту, коли вам потрібні звичайний CI плюс live prompt cache, Docker, QA Lab,
|
||||
Matrix і Telegram покриття з одного ручного workflow
|
||||
4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть
|
||||
ручний workflow `CI` на ref релізу
|
||||
- До появи тегу можна використовувати поточний повний SHA коміту гілки workflow
|
||||
для dry run workflow preflight лише з метою валідації
|
||||
2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
|
||||
коли ви навмисно хочете пряму stable-публікацію
|
||||
3. Запустіть `Full Release Validation` для гілки релізу, тега релізу або повного
|
||||
SHA коміту, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab,
|
||||
Matrix і Telegram з одного ручного workflow
|
||||
4. Якщо навмисно потрібен лише детермінований звичайний тестовий граф, замість цього запустіть
|
||||
ручний workflow `CI` для ref релізу
|
||||
5. Збережіть успішний `preflight_run_id`
|
||||
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`,
|
||||
щоб просунути цю stable-версію з `beta` до `latest`
|
||||
8. Якщо реліз навмисно було опубліковано одразу в `latest` і `beta`
|
||||
має негайно наслідувати ту саму stable-збірку, використовуйте той самий приватний
|
||||
workflow, щоб націлити обидва dist-tag на stable-версію, або дозвольте його запланованій
|
||||
self-healing синхронізації пересунути `beta` пізніше
|
||||
8. Якщо реліз навмисно був опублікований безпосередньо в `latest`, а `beta`
|
||||
має одразу слідувати за тією ж stable-збіркою, використайте той самий приватний
|
||||
workflow, щоб спрямувати обидва dist-tag на stable-версію, або дозвольте його запланованій
|
||||
self-healing синхронізації перемістити `beta` пізніше
|
||||
|
||||
Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, тому що вона все ще
|
||||
Мутація dist-tag живе в приватному репозиторії з міркувань безпеки, оскільки вона все ще
|
||||
потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
|
||||
|
||||
Це робить як шлях прямої публікації, так і шлях beta-first просування
|
||||
Це зберігає і шлях прямої публікації, і шлях просування beta-first
|
||||
задокументованими та видимими для оператора.
|
||||
|
||||
Якщо супровіднику доводиться перейти до локальної npm-автентифікації, виконуйте будь-які команди
|
||||
1Password CLI (`op`) лише в межах окремої tmux-сесії. Не викликайте `op`
|
||||
безпосередньо з основної оболонки агента; запуск усередині tmux робить запити,
|
||||
сповіщення та обробку OTP спостережуваними й запобігає повторним сповіщенням хоста.
|
||||
Якщо мейнтейнеру доводиться повертатися до локальної npm-автентифікації, виконуйте будь-які команди
|
||||
1Password CLI (`op`) лише в окремій сесії tmux. Не викликайте `op`
|
||||
безпосередньо з основної оболонки агента; запуск усередині tmux робить prompts,
|
||||
alerts і обробку OTP спостережуваними та запобігає повторним сповіщенням на хості.
|
||||
|
||||
## Публічні посилання
|
||||
|
||||
@ -508,10 +512,10 @@ workflow Telegram, як і раніше, приймає опубліковану
|
||||
- [`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)
|
||||
|
||||
Супровідники використовують приватну документацію релізів у
|
||||
Мейнтейнери використовують приватну документацію релізу в
|
||||
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
|
||||
як фактичний runbook.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Канали релізів](/uk/install/development-channels)
|
||||
- [Канали релізу](/uk/install/development-channels)
|
||||
|
||||
@ -3,20 +3,20 @@ read_when:
|
||||
- Використання або налаштування команд чату
|
||||
- Налагодження маршрутизації команд або дозволів
|
||||
sidebarTitle: Slash commands
|
||||
summary: 'Слеш-команди: текстові проти нативних, конфігурація та підтримувані команди'
|
||||
summary: 'Слеш-команди: текстові чи нативні, конфігурація та підтримувані команди'
|
||||
title: Слеш-команди
|
||||
x-i18n:
|
||||
generated_at: "2026-04-26T08:15:42Z"
|
||||
generated_at: "2026-04-27T21:05:09Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 75bf58d02738e30bfdc00ad1c264b2f066eebd2819f4ea0209f504f279755993
|
||||
source_hash: ce0d9d28e74cd81d0484990dab6a4c83ea03a84d267f78f0488c53552ddcba38
|
||||
source_path: tools/slash-commands.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Команди обробляються Gateway. Більшість команд потрібно надсилати як **окреме** повідомлення, що починається з `/`. Команда чату bash лише для хоста використовує `! <cmd>` (з псевдонімом `/bash <cmd>`).
|
||||
Команди обробляє Gateway. Більшість команд потрібно надсилати як **окреме** повідомлення, яке починається з `/`. Чат-команда bash лише для хоста використовує `! <cmd>` (із псевдонімом `/bash <cmd>`).
|
||||
|
||||
Коли розмову або тред прив’язано до сесії ACP, звичайний подальший текст маршрутизується до цього harness ACP. Команди керування Gateway все одно залишаються локальними: `/acp ...` завжди потрапляє до обробника команд OpenClaw ACP, а `/status` і `/unfocus` залишаються локальними щоразу, коли для цієї поверхні ввімкнено обробку команд.
|
||||
Коли розмова або гілка прив’язана до сеансу ACP, звичайний подальший текст маршрутизується до цього ACP harness. Команди керування Gateway усе одно залишаються локальними: `/acp ...` завжди потрапляє до обробника команд OpenClaw ACP, а `/status` і `/unfocus` залишаються локальними всюди, де для цієї поверхні ввімкнено обробку команд.
|
||||
|
||||
Є дві пов’язані системи:
|
||||
|
||||
@ -27,16 +27,16 @@ x-i18n:
|
||||
<Accordion title="Директиви">
|
||||
`/think`, `/fast`, `/verbose`, `/trace`, `/reasoning`, `/elevated`, `/exec`, `/model`, `/queue`.
|
||||
|
||||
- Директиви вилучаються з повідомлення до того, як модель його побачить.
|
||||
- У звичайних повідомленнях чату (не лише з директивами) вони трактуються як "вбудовані підказки" і **не** зберігають налаштування сесії.
|
||||
- У повідомленнях лише з директивами (повідомлення містить тільки директиви) вони зберігаються в сесії та повертають підтвердження.
|
||||
- Директиви застосовуються лише для **авторизованих відправників**. Якщо задано `commands.allowFrom`, використовується лише цей список дозволу; інакше авторизація походить зі списків дозволу каналу/прив’язки плюс `commands.useAccessGroups`. Для неавторизованих відправників директиви трактуються як звичайний текст.
|
||||
- Директиви видаляються з повідомлення до того, як його побачить модель.
|
||||
- У звичайних чат-повідомленнях (не лише з директивами) вони розглядаються як «вбудовані підказки» і **не** зберігають налаштування сеансу.
|
||||
- У повідомленнях лише з директивами (повідомлення містить тільки директиви) вони зберігаються в сеансі та повертають підтвердження.
|
||||
- Директиви застосовуються лише для **авторизованих відправників**. Якщо задано `commands.allowFrom`, використовується лише цей список дозволених; інакше авторизація визначається списками дозволених каналу/спарюванням і `commands.useAccessGroups`. Для неавторизованих відправників директиви обробляються як звичайний текст.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Вбудовані скорочення">
|
||||
Лише для відправників зі списку дозволу/авторизованих: `/help`, `/commands`, `/status`, `/whoami` (`/id`).
|
||||
Лише для відправників зі списку дозволених/авторизованих: `/help`, `/commands`, `/status`, `/whoami` (`/id`).
|
||||
|
||||
Вони виконуються негайно, вилучаються до того, як модель побачить повідомлення, а решта тексту продовжує проходити звичайним потоком.
|
||||
Вони виконуються негайно, видаляються до того, як повідомлення побачить модель, а решта тексту проходить звичайним шляхом.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -69,16 +69,16 @@ x-i18n:
|
||||
```
|
||||
|
||||
<ParamField path="commands.text" type="boolean" default="true">
|
||||
Вмикає розбір `/...` у повідомленнях чату. На поверхнях без нативних команд (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) текстові команди все одно працюють, навіть якщо встановити `false`.
|
||||
Вмикає розбір `/...` у чат-повідомленнях. На поверхнях без нативних команд (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) текстові команди все одно працюють, навіть якщо встановити `false`.
|
||||
</ParamField>
|
||||
<ParamField path="commands.native" type='boolean | "auto"' default='"auto"'>
|
||||
Реєструє нативні команди. Авто: увімкнено для Discord/Telegram; вимкнено для Slack (доки ви не додасте слеш-команди); ігнорується для провайдерів без нативної підтримки. Щоб перевизначити для окремого провайдера, задайте `channels.discord.commands.native`, `channels.telegram.commands.native` або `channels.slack.commands.native` (bool або `"auto"`). Значення `false` очищає раніше зареєстровані команди в Discord/Telegram під час запуску. Команди Slack керуються у застосунку Slack і не видаляються автоматично.
|
||||
Реєструє нативні команди. Auto: увімкнено для Discord/Telegram; вимкнено для Slack (поки ви не додасте slash-команди); ігнорується для провайдерів без нативної підтримки. Щоб перевизначити для конкретного провайдера, установіть `channels.discord.commands.native`, `channels.telegram.commands.native` або `channels.slack.commands.native` (bool або `"auto"`). Значення `false` очищає раніше зареєстровані команди в Discord/Telegram під час запуску. Команди Slack керуються в застосунку Slack і не видаляються автоматично.
|
||||
</ParamField>
|
||||
<ParamField path="commands.nativeSkills" type='boolean | "auto"' default='"auto"'>
|
||||
Реєструє команди **Skills** нативно, коли це підтримується. Авто: увімкнено для Discord/Telegram; вимкнено для Slack (у Slack потрібно створити слеш-команду для кожного skill). Щоб перевизначити для окремого провайдера, задайте `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` або `channels.slack.commands.nativeSkills` (bool або `"auto"`).
|
||||
Реєструє нативно команди **Skill**, якщо це підтримується. Auto: увімкнено для Discord/Telegram; вимкнено для Slack (у Slack потрібно створити slash-команду для кожного Skill). Щоб перевизначити для конкретного провайдера, установіть `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` або `channels.slack.commands.nativeSkills` (bool або `"auto"`).
|
||||
</ParamField>
|
||||
<ParamField path="commands.bash" type="boolean" default="false">
|
||||
Вмикає `! <cmd>` для запуску shell-команд хоста (`/bash <cmd>` — псевдонім; потребує списків дозволу `tools.elevated`).
|
||||
Вмикає `! <cmd>` для виконання команд shell на хості (`/bash <cmd>` — псевдонім; потрібні списки дозволених `tools.elevated`).
|
||||
</ParamField>
|
||||
<ParamField path="commands.bashForegroundMs" type="number" default="2000">
|
||||
Керує тим, скільки часу bash чекає перед переходом у фоновий режим (`0` одразу переводить у фон).
|
||||
@ -90,7 +90,7 @@ x-i18n:
|
||||
Вмикає `/mcp` (читає/записує конфігурацію MCP, якою керує OpenClaw, у `mcp.servers`).
|
||||
</ParamField>
|
||||
<ParamField path="commands.plugins" type="boolean" default="false">
|
||||
Вмикає `/plugins` (виявлення/статус plugin-ів, а також керування встановленням і ввімкненням/вимкненням).
|
||||
Вмикає `/plugins` (виявлення/стан плагінів, а також встановлення й елементи керування ввімкненням/вимкненням).
|
||||
</ParamField>
|
||||
<ParamField path="commands.debug" type="boolean" default="false">
|
||||
Вмикає `/debug` (лише перевизначення під час виконання).
|
||||
@ -99,119 +99,121 @@ x-i18n:
|
||||
Вмикає `/restart`, а також дії інструментів перезапуску gateway.
|
||||
</ParamField>
|
||||
<ParamField path="commands.ownerAllowFrom" type="string[]">
|
||||
Встановлює явний список дозволу власника для поверхонь команд/інструментів, доступних лише власнику. Окремо від `commands.allowFrom`.
|
||||
Задає явний список дозволених для власника для поверхонь команд/інструментів лише для власника. Окремо від `commands.allowFrom`.
|
||||
</ParamField>
|
||||
<ParamField path="channels.<channel>.commands.enforceOwnerForCommands" type="boolean" default="false">
|
||||
Для кожного каналу: змушує команди лише для власника вимагати **ідентичність власника** для виконання на цій поверхні. Якщо `true`, відправник має або відповідати визначеному кандидату у власники (наприклад, запису в `commands.ownerAllowFrom` або нативним метаданим власника провайдера), або мати внутрішню область доступу `operator.admin` на внутрішньому каналі повідомлень. Підстановний запис у `allowFrom` каналу або порожній/невизначений список кандидатів у власники **не** є достатнім — команди лише для власника в цьому каналі забороняються за замовчуванням. Залишайте це вимкненим, якщо хочете, щоб команди лише для власника обмежувалися лише `ownerAllowFrom` і стандартними списками дозволу команд.
|
||||
Для кожного каналу: змушує команди лише для власника вимагати **ідентичність власника** для виконання на цій поверхні. Якщо `true`, відправник має або відповідати визначеному кандидату у власники (наприклад, запису в `commands.ownerAllowFrom` або нативним метаданим власника провайдера), або мати внутрішню область дії `operator.admin` на внутрішньому каналі повідомлень. Запис-шаблон у `allowFrom` каналу або порожній/невизначений список кандидатів у власники **не** є достатнім — команди лише для власника в цьому каналі за замовчуванням блокуються. Залиште це вимкненим, якщо хочете, щоб команди лише для власника обмежувалися лише `ownerAllowFrom` і стандартними списками дозволених для команд.
|
||||
</ParamField>
|
||||
<ParamField path="commands.ownerDisplay" type='"raw" | "hash"'>
|
||||
Керує тим, як ідентифікатори власника відображаються в системному prompt.
|
||||
Керує тим, як ідентифікатори власника відображаються в system prompt.
|
||||
</ParamField>
|
||||
<ParamField path="commands.ownerDisplaySecret" type="string">
|
||||
За потреби задає секрет HMAC, який використовується, коли `commands.ownerDisplay="hash"`.
|
||||
Необов’язково задає секрет HMAC, який використовується, коли `commands.ownerDisplay="hash"`.
|
||||
</ParamField>
|
||||
<ParamField path="commands.allowFrom" type="object">
|
||||
Список дозволу для авторизації команд за провайдером. Якщо налаштовано, це єдине джерело авторизації для команд і директив (списки дозволу каналу/прив’язки та `commands.useAccessGroups` ігноруються). Використовуйте `"*"` як глобальне значення за замовчуванням; ключі для конкретних провайдерів мають пріоритет.
|
||||
Список дозволених за провайдером для авторизації команд. Якщо налаштовано, це єдине джерело авторизації для команд і директив (списки дозволених каналу/спарювання та `commands.useAccessGroups` ігноруються). Використовуйте `"*"` як глобальне значення за замовчуванням; ключі конкретних провайдерів мають вищий пріоритет.
|
||||
</ParamField>
|
||||
<ParamField path="commands.useAccessGroups" type="boolean" default="true">
|
||||
Застосовує списки дозволу/політики до команд, якщо `commands.allowFrom` не задано.
|
||||
Застосовує списки дозволених/політики для команд, коли `commands.allowFrom` не задано.
|
||||
</ParamField>
|
||||
|
||||
## Список команд
|
||||
|
||||
Поточне джерело істини:
|
||||
|
||||
- вбудовані core-команди походять із `src/auto-reply/commands-registry.shared.ts`
|
||||
- згенеровані dock-команди походять із `src/auto-reply/commands-registry.data.ts`
|
||||
- команди plugin-ів походять із викликів `registerCommand()` у plugin-ах
|
||||
- фактична доступність у вашому gateway усе одно залежить від прапорців конфігурації, поверхні каналу та встановлених/увімкнених plugin-ів
|
||||
- вбудовані базові команди походять із `src/auto-reply/commands-registry.shared.ts`
|
||||
- згенеровані команди dock походять із `src/auto-reply/commands-registry.data.ts`
|
||||
- команди плагінів походять із викликів `registerCommand()` плагінів
|
||||
- фактична доступність у вашому gateway усе одно залежить від прапорців конфігурації, поверхні каналу та встановлених/увімкнених плагінів
|
||||
|
||||
### Вбудовані команди core
|
||||
### Вбудовані базові команди
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Сесії та запуски">
|
||||
- `/new [model]` запускає нову сесію; `/reset` — псевдонім для скидання.
|
||||
- `/reset soft [message]` зберігає поточний transcript, скидає повторно використані ідентифікатори сесій CLI backend і повторно запускає завантаження startup/system-prompt на місці.
|
||||
- `/compact [instructions]` стискає контекст сесії. Див. [Compaction](/uk/concepts/compaction).
|
||||
<Accordion title="Сеанси та запуски">
|
||||
- `/new [model]` запускає новий сеанс; `/reset` — псевдонім для скидання.
|
||||
- `/reset soft [message]` зберігає поточний transcript, скидає повторно використані ідентифікатори сеансів CLI backend і повторно запускає завантаження startup/system prompt на місці.
|
||||
- `/compact [instructions]` стискає контекст сеансу. Див. [Compaction](/uk/concepts/compaction).
|
||||
- `/stop` перериває поточний запуск.
|
||||
- `/session idle <duration|off>` і `/session max-age <duration|off>` керують строком дії прив’язки до треду.
|
||||
- `/export-session [path]` експортує поточну сесію в HTML. Псевдонім: `/export`.
|
||||
- `/export-trajectory [path]` експортує JSONL [trajectory bundle](/uk/tools/trajectory) для поточної сесії. Псевдонім: `/trajectory`.
|
||||
- `/session idle <duration|off>` і `/session max-age <duration|off>` керують строком дії прив’язки до гілки.
|
||||
- `/export-session [path]` експортує поточний сеанс у HTML. Псевдонім: `/export`.
|
||||
- `/export-trajectory [path]` експортує JSONL [trajectory bundle](/uk/tools/trajectory) для поточного сеансу. Псевдонім: `/trajectory`.
|
||||
</Accordion>
|
||||
<Accordion title="Модель і керування запуском">
|
||||
- `/think <level>` задає рівень мислення. Варіанти надходять із профілю провайдера активної моделі; поширені рівні: `off`, `minimal`, `low`, `medium` і `high`, а також спеціальні рівні на кшталт `xhigh`, `adaptive`, `max` або бінарний `on` лише там, де це підтримується. Псевдоніми: `/thinking`, `/t`.
|
||||
- `/think <level>` задає рівень мислення. Варіанти надходять із профілю провайдера активної моделі; поширені рівні — `off`, `minimal`, `low`, `medium` і `high`, а також користувацькі рівні, як-от `xhigh`, `adaptive`, `max`, або двійкове `on` лише там, де це підтримується. Псевдоніми: `/thinking`, `/t`.
|
||||
- `/verbose on|off|full` перемикає докладний вивід. Псевдонім: `/v`.
|
||||
- `/trace on|off` перемикає вивід трасування plugin-ів для поточної сесії.
|
||||
- `/trace on|off` перемикає вивід трасування плагіна для поточного сеансу.
|
||||
- `/fast [status|on|off]` показує або задає швидкий режим.
|
||||
- `/reasoning [on|off|stream]` перемикає видимість reasoning. Псевдонім: `/reason`.
|
||||
- `/elevated [on|off|ask|full]` перемикає elevated mode. Псевдонім: `/elev`.
|
||||
- `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` показує або задає значення exec за замовчуванням.
|
||||
- `/reasoning [on|off|stream]` перемикає видимість міркувань. Псевдонім: `/reason`.
|
||||
- `/elevated [on|off|ask|full]` перемикає режим elevated. Псевдонім: `/elev`.
|
||||
- `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` показує або задає типові значення exec.
|
||||
- `/model [name|#|status]` показує або задає модель.
|
||||
- `/models [provider] [page] [limit=<n>|size=<n>|all]` перелічує провайдерів або моделі для провайдера.
|
||||
- `/queue <mode>` керує поведінкою черги (`steer`, `interrupt`, `followup`, `collect`, `steer-backlog`), а також параметрами на кшталт `debounce:2s cap:25 drop:summarize`.
|
||||
</Accordion>
|
||||
<Accordion title="Виявлення та статус">
|
||||
<Accordion title="Виявлення та стан">
|
||||
- `/help` показує короткий довідковий підсумок.
|
||||
- `/commands` показує згенерований каталог команд.
|
||||
- `/tools [compact|verbose]` показує, чим поточний агент може користуватися прямо зараз.
|
||||
- `/status` показує статус виконання/середовища виконання, зокрема мітки `Execution`/`Runtime` і використання/квоти провайдера, якщо доступно.
|
||||
- `/crestodian <request>` запускає помічник налаштування й відновлення Crestodian із приватного повідомлення власника.
|
||||
- `/tasks` перелічує активні/нещодавні фонові завдання для поточної сесії.
|
||||
- `/tools [compact|verbose]` показує, що поточний агент може використовувати просто зараз.
|
||||
- `/status` показує стан виконання/середовища виконання, включно з мітками `Execution`/`Runtime` і використанням/квотою провайдера, якщо доступно.
|
||||
- `/crestodian <request>` запускає помічник налаштування та відновлення Crestodian із DM власника.
|
||||
- `/tasks` перелічує активні/нещодавні фонові завдання для поточного сеансу.
|
||||
- `/context [list|detail|json]` пояснює, як збирається контекст.
|
||||
- `/whoami` показує ваш ідентифікатор відправника. Псевдонім: `/id`.
|
||||
- `/usage off|tokens|full|cost` керує нижнім колонтитулом використання для кожної відповіді або виводить локальний підсумок вартості.
|
||||
</Accordion>
|
||||
<Accordion title="Skills, списки дозволу, підтвердження">
|
||||
- `/skill <name> [input]` запускає skill за назвою.
|
||||
- `/allowlist [list|add|remove] ...` керує записами списку дозволу. Лише текстовий режим.
|
||||
- `/approve <id> <decision>` обробляє запити на підтвердження exec.
|
||||
- `/btw <question>` ставить побічне запитання без зміни майбутнього контексту сесії. Див. [BTW](/uk/tools/btw).
|
||||
<Accordion title="Skills, списки дозволених, схвалення">
|
||||
- `/skill <name> [input]` запускає Skill за назвою.
|
||||
- `/allowlist [list|add|remove] ...` керує записами списку дозволених. Лише текст.
|
||||
- `/approve <id> <decision>` обробляє запити на схвалення exec.
|
||||
- `/btw <question>` ставить побічне запитання без зміни майбутнього контексту сеансу. Див. [BTW](/uk/tools/btw).
|
||||
</Accordion>
|
||||
<Accordion title="Subagent-и та ACP">
|
||||
- `/subagents list|kill|log|info|send|steer|spawn` керує запусками subagent-ів для поточної сесії.
|
||||
- `/acp spawn|cancel|steer|close|sessions|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|help` керує сесіями ACP і параметрами середовища виконання.
|
||||
- `/focus <target>` прив’язує поточний тред Discord або тему/розмову Telegram до цільової сесії.
|
||||
- `/unfocus` знімає поточну прив’язку.
|
||||
- `/agents` перелічує агентів, прив’язаних до треду, для поточної сесії.
|
||||
- `/kill <id|#|all>` перериває один або всі запущені subagent-и.
|
||||
- `/steer <id|#> <message>` надсилає керуюче повідомлення до запущеного subagent-а. Псевдонім: `/tell`.
|
||||
<Accordion title="Subagents і ACP">
|
||||
- `/subagents list|kill|log|info|send|steer|spawn` керує запусками sub-agent для поточного сеансу.
|
||||
- `/acp spawn|cancel|steer|close|sessions|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|help` керує сеансами ACP і параметрами середовища виконання.
|
||||
- `/focus <target>` прив’язує поточну гілку Discord або тему/розмову Telegram до цільового сеансу.
|
||||
- `/unfocus` видаляє поточну прив’язку.
|
||||
- `/agents` перелічує агентів, прив’язаних до гілки, для поточного сеансу.
|
||||
- `/kill <id|#|all>` перериває один або всі запущені sub-agent.
|
||||
- `/steer <id|#> <message>` надсилає керування запущеному sub-agent. Псевдонім: `/tell`.
|
||||
</Accordion>
|
||||
<Accordion title="Запис і адміністрування лише для власника">
|
||||
- `/config show|get|set|unset` читає або записує `openclaw.json`. Лише для власника. Потребує `commands.config: true`.
|
||||
- `/mcp show|get|set|unset` читає або записує конфігурацію сервера MCP, якою керує OpenClaw, у `mcp.servers`. Лише для власника. Потребує `commands.mcp: true`.
|
||||
- `/plugins list|inspect|show|get|install|enable|disable` перевіряє або змінює стан plugin-ів. `/plugin` — псевдонім. Запис — лише для власника. Потребує `commands.plugins: true`.
|
||||
- `/debug show|set|unset|reset` керує перевизначеннями конфігурації лише під час виконання. Лише для власника. Потребує `commands.debug: true`.
|
||||
- `/restart` перезапускає OpenClaw, якщо ввімкнено. За замовчуванням: увімкнено; щоб вимкнути, задайте `commands.restart: false`.
|
||||
<Accordion title="Запис лише для власника та адміністрування">
|
||||
- `/config show|get|set|unset` читає або записує `openclaw.json`. Лише для власника. Потрібно `commands.config: true`.
|
||||
- `/mcp show|get|set|unset` читає або записує конфігурацію MCP-сервера, якою керує OpenClaw, у `mcp.servers`. Лише для власника. Потрібно `commands.mcp: true`.
|
||||
- `/plugins list|inspect|show|get|install|enable|disable` перевіряє або змінює стан плагіна. `/plugin` — псевдонім. Запис — лише для власника. Потрібно `commands.plugins: true`.
|
||||
- `/debug show|set|unset|reset` керує перевизначеннями конфігурації лише під час виконання. Лише для власника. Потрібно `commands.debug: true`.
|
||||
- `/restart` перезапускає OpenClaw, якщо ввімкнено. Типово: увімкнено; установіть `commands.restart: false`, щоб вимкнути.
|
||||
- `/send on|off|inherit` задає політику надсилання. Лише для власника.
|
||||
</Accordion>
|
||||
<Accordion title="Голос, TTS, керування каналом">
|
||||
- `/tts on|off|status|chat|latest|provider|limit|summary|audio|help` керує TTS. Див. [TTS](/uk/tools/tts).
|
||||
- `/activation mention|always` задає режим активації групи.
|
||||
- `/bash <command>` запускає shell-команду хоста. Лише текстовий режим. Псевдонім: `! <command>`. Потребує `commands.bash: true` і списків дозволу `tools.elevated`.
|
||||
- `/bash <command>` запускає команду shell на хості. Лише текст. Псевдонім: `! <command>`. Потрібно `commands.bash: true` і списки дозволених `tools.elevated`.
|
||||
- `!poll [sessionId]` перевіряє фонове завдання bash.
|
||||
- `!stop [sessionId]` зупиняє фонове завдання bash.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
### Згенеровані dock-команди
|
||||
### Згенеровані команди dock
|
||||
|
||||
Dock-команди генеруються з channel plugin-ів із підтримкою нативних команд. Поточний вбудований набір:
|
||||
Команди dock генеруються з плагінів каналів із підтримкою нативних команд. Поточний вбудований набір:
|
||||
|
||||
- `/dock-discord` (псевдонім: `/dock_discord`)
|
||||
- `/dock-mattermost` (псевдонім: `/dock_mattermost`)
|
||||
- `/dock-slack` (псевдонім: `/dock_slack`)
|
||||
- `/dock-telegram` (псевдонім: `/dock_telegram`)
|
||||
|
||||
### Команди вбудованих plugin-ів
|
||||
Використовуйте команди dock із прямого чату, щоб перемкнути маршрут відповіді поточного сеансу на інший пов’язаний канал. Відправник джерела й цільовий співрозмовник мають бути в одній групі `session.identityLinks`, наприклад `["telegram:123", "discord:456"]`.
|
||||
|
||||
Вбудовані plugin-и можуть додавати більше слеш-команд. Поточні вбудовані команди в цьому репозиторії:
|
||||
### Команди вбудованих плагінів
|
||||
|
||||
- `/dreaming [on|off|status|help]` перемикає Dreaming пам’яті. Див. [Dreaming](/uk/concepts/dreaming).
|
||||
- `/pair [qr|status|pending|approve|cleanup|notify]` керує потоком прив’язки/налаштування пристрою. Див. [Pairing](/uk/channels/pairing).
|
||||
- `/phone status|arm <camera|screen|writes|all> [duration]|disarm` тимчасово озброює високоризикові команди вузла телефону.
|
||||
Вбудовані плагіни можуть додавати більше slash-команд. Поточні вбудовані команди в цьому репозиторії:
|
||||
|
||||
- `/dreaming [on|off|status|help]` перемикає memory dreaming. Див. [Dreaming](/uk/concepts/dreaming).
|
||||
- `/pair [qr|status|pending|approve|cleanup|notify]` керує потоком спарювання/налаштування пристрою. Див. [Pairing](/uk/channels/pairing).
|
||||
- `/phone status|arm <camera|screen|writes|all> [duration]|disarm` тимчасово вмикає високоризикові команди phone node.
|
||||
- `/voice status|list [limit]|set <voiceId|name>` керує конфігурацією голосу Talk. У Discord назва нативної команди — `/talkvoice`.
|
||||
- `/card ...` надсилає набори rich card для LINE. Див. [LINE](/uk/channels/line).
|
||||
- `/codex status|models|threads|resume|compact|review|account|mcp|skills` перевіряє та керує вбудованим harness app-server Codex. Див. [Codex harness](/uk/plugins/codex-harness).
|
||||
- `/card ...` надсилає попередньо налаштовані rich card для LINE. Див. [LINE](/uk/channels/line).
|
||||
- `/codex status|models|threads|resume|compact|review|account|mcp|skills` перевіряє та керує вбудованим app-server harness Codex. Див. [Codex harness](/uk/plugins/codex-harness).
|
||||
- Команди лише для QQBot:
|
||||
- `/bot-ping`
|
||||
- `/bot-version`
|
||||
@ -219,83 +221,83 @@ Dock-команди генеруються з channel plugin-ів із підт
|
||||
- `/bot-upgrade`
|
||||
- `/bot-logs`
|
||||
|
||||
### Динамічні команди skill-ів
|
||||
### Динамічні команди Skill
|
||||
|
||||
Skills, які може викликати користувач, також доступні як слеш-команди:
|
||||
Skills, які може викликати користувач, також доступні як slash-команди:
|
||||
|
||||
- `/skill <name> [input]` завжди працює як універсальна точка входу.
|
||||
- skills також можуть з’являтися як прямі команди, наприклад `/prose`, коли їх реєструє skill/plugin.
|
||||
- реєстрація нативних команд skill-ів керується через `commands.nativeSkills` і `channels.<provider>.commands.nativeSkills`.
|
||||
- `/skill <name> [input]` завжди працює як загальна точка входу.
|
||||
- Skills також можуть з’являтися як прямі команди на кшталт `/prose`, коли Skill/плагін їх реєструє.
|
||||
- Реєстрація нативних команд Skill керується `commands.nativeSkills` і `channels.<provider>.commands.nativeSkills`.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Нотатки щодо аргументів і парсера">
|
||||
- Команди приймають необов’язковий `:` між командою та аргументами (наприклад, `/think: high`, `/send: on`, `/help:`).
|
||||
- `/new <model>` приймає псевдонім моделі, `provider/model` або назву провайдера (нечіткий збіг); якщо збігу немає, текст трактується як тіло повідомлення.
|
||||
- Для повного розподілу використання за провайдерами використовуйте `openclaw status --usage`.
|
||||
<Accordion title="Нотатки про аргументи та парсер">
|
||||
- Команди приймають необов’язковий `:` між командою й аргументами (наприклад, `/think: high`, `/send: on`, `/help:`).
|
||||
- `/new <model>` приймає псевдонім моделі, `provider/model` або назву провайдера (нечіткий збіг); якщо збігу немає, текст обробляється як тіло повідомлення.
|
||||
- Для повного розподілу використання провайдера використовуйте `openclaw status --usage`.
|
||||
- `/allowlist add|remove` потребує `commands.config=true` і враховує `configWrites` каналу.
|
||||
- У каналах із кількома обліковими записами `/allowlist --account <id>`, націлений на конфігурацію, і `/config set channels.<provider>.accounts.<id>...` також враховують `configWrites` цільового облікового запису.
|
||||
- `/usage` керує нижнім колонтитулом використання для кожної відповіді; `/usage cost` виводить локальний підсумок вартості з логів сесій OpenClaw.
|
||||
- `/restart` увімкнено за замовчуванням; щоб вимкнути, задайте `commands.restart: false`.
|
||||
- `/plugins install <spec>` приймає ті самі специфікації plugin-ів, що й `openclaw plugins install`: локальний шлях/архів, npm-пакет або `clawhub:<pkg>`.
|
||||
- `/plugins enable|disable` оновлює конфігурацію plugin-ів і може запросити перезапуск.
|
||||
- У багатoоблікових каналах орієнтовані на конфігурацію `/allowlist --account <id>` і `/config set channels.<provider>.accounts.<id>...` також враховують `configWrites` цільового облікового запису.
|
||||
- `/usage` керує нижнім колонтитулом використання для кожної відповіді; `/usage cost` виводить локальний підсумок вартості з журналів сеансу OpenClaw.
|
||||
- `/restart` увімкнено за замовчуванням; установіть `commands.restart: false`, щоб вимкнути його.
|
||||
- `/plugins install <spec>` приймає ті самі специфікації плагінів, що й `openclaw plugins install`: локальний шлях/архів, npm package або `clawhub:<pkg>`.
|
||||
- `/plugins enable|disable` оновлює конфігурацію плагіна й може запропонувати перезапуск.
|
||||
</Accordion>
|
||||
<Accordion title="Поведінка для конкретних каналів">
|
||||
- Нативна команда лише для Discord: `/vc join|leave|status` керує голосовими каналами (недоступна як текстова команда). `join` потребує guild і вибраного голосового/stage-каналу. Потребує `channels.discord.voice` і нативних команд.
|
||||
- Команди прив’язки до тредів Discord (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) потребують, щоб ефективні прив’язки до тредів були ввімкнені (`session.threadBindings.enabled` і/або `channels.discord.threadBindings.enabled`).
|
||||
- Нативна команда лише для Discord: `/vc join|leave|status` керує голосовими каналами (недоступна як текст). `join` потребує guild і вибраного голосового/stage-каналу. Потрібні `channels.discord.voice` і нативні команди.
|
||||
- Команди прив’язки до гілки Discord (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) вимагають, щоб ефективні прив’язки до гілки були ввімкнені (`session.threadBindings.enabled` і/або `channels.discord.threadBindings.enabled`).
|
||||
- Довідник команд ACP і поведінка середовища виконання: [ACP agents](/uk/tools/acp-agents).
|
||||
</Accordion>
|
||||
<Accordion title="Безпека verbose / trace / fast / reasoning">
|
||||
- `/verbose` призначено для налагодження та додаткової видимості; у звичайному використанні тримайте його **вимкненим**.
|
||||
- `/trace` вужчий за `/verbose`: він показує лише рядки trace/debug, що належать plugin-ам, і не вмикає звичайну докладну балаканину інструментів.
|
||||
- `/fast on|off` зберігає перевизначення сесії. Щоб очистити його й повернутися до значень конфігурації за замовчуванням, використовуйте опцію `inherit` в інтерфейсі Sessions.
|
||||
- `/fast` залежить від провайдера: OpenAI/OpenAI Codex зіставляють його з `service_tier=priority` на нативних ендпоінтах Responses, тоді як прямі публічні запити Anthropic, зокрема трафік з автентифікацією OAuth, надісланий до `api.anthropic.com`, зіставляють його з `service_tier=auto` або `standard_only`. Див. [OpenAI](/uk/providers/openai) і [Anthropic](/uk/providers/anthropic).
|
||||
- Підсумки помилок інструментів усе одно показуються, коли це доречно, але детальний текст помилки включається лише коли `/verbose` має значення `on` або `full`.
|
||||
- `/reasoning`, `/verbose` і `/trace` ризиковані в групових налаштуваннях: вони можуть розкрити внутрішнє reasoning, вивід інструментів або діагностику plugin-ів, які ви не мали наміру показувати. Краще залишати їх вимкненими, особливо в групових чатах.
|
||||
- `/verbose` призначено для налагодження й додаткової видимості; у звичайному використанні тримайте його **вимкненим**.
|
||||
- `/trace` вужчий за `/verbose`: він показує лише рядки trace/debug, що належать плагіну, і не вмикає звичайний докладний вивід інструментів.
|
||||
- `/fast on|off` зберігає перевизначення для сеансу. Щоб очистити його й повернутися до значень конфігурації за замовчуванням, використовуйте опцію `inherit` в інтерфейсі Sessions.
|
||||
- `/fast` залежить від провайдера: OpenAI/OpenAI Codex зіставляють його з `service_tier=priority` на нативних endpoints Responses, тоді як прямі публічні запити Anthropic, зокрема трафік з автентифікацією OAuth, надісланий до `api.anthropic.com`, зіставляють його з `service_tier=auto` або `standard_only`. Див. [OpenAI](/uk/providers/openai) і [Anthropic](/uk/providers/anthropic).
|
||||
- Підсумки збоїв інструментів усе одно показуються, коли це доречно, але детальний текст збою включається лише коли `/verbose` має значення `on` або `full`.
|
||||
- `/reasoning`, `/verbose` і `/trace` ризиковані в групових налаштуваннях: вони можуть розкрити внутрішні міркування, вивід інструментів або діагностику плагіна, яку ви не планували показувати. Краще залишати їх вимкненими, особливо в групових чатах.
|
||||
</Accordion>
|
||||
<Accordion title="Перемикання моделі">
|
||||
- `/model` негайно зберігає нову модель сесії.
|
||||
- Якщо агент неактивний, наступний запуск одразу її використовує.
|
||||
- Якщо запуск уже активний, OpenClaw позначає живе перемикання як відкладене і перезапускає з новою моделлю лише в чистій точці повторної спроби.
|
||||
- Якщо активність інструментів або вивід відповіді вже почалися, відкладене перемикання може залишатися в черзі до пізнішої можливості повторної спроби або до наступного ходу користувача.
|
||||
- У локальному TUI `/crestodian [request]` повертає зі звичайного TUI агента до Crestodian. Це окремо від режиму порятунку каналу повідомлень і не надає віддалених повноважень на зміну конфігурації.
|
||||
- `/model` негайно зберігає нову модель сеансу.
|
||||
- Якщо агент неактивний, наступний запуск одразу її використає.
|
||||
- Якщо запуск уже активний, OpenClaw позначає живе перемикання як відкладене й перезапускає на новій моделі лише в чистій точці повторної спроби.
|
||||
- Якщо активність інструмента або вивід відповіді вже почалися, відкладене перемикання може залишатися в черзі до пізнішої можливості повторної спроби або до наступного ходу користувача.
|
||||
- У локальному TUI, `/crestodian [request]` повертає з нормального TUI агента до Crestodian. Це окремо від режиму порятунку каналу повідомлень і не надає віддалених повноважень на зміну конфігурації.
|
||||
</Accordion>
|
||||
<Accordion title="Швидкий шлях і вбудовані скорочення">
|
||||
- **Швидкий шлях:** повідомлення лише з командами від відправників зі списку дозволу обробляються негайно (обхід черги + моделі).
|
||||
- **Обмеження згадкою в групі:** повідомлення лише з командами від відправників зі списку дозволу обходять вимоги згадки.
|
||||
- **Вбудовані скорочення (лише для відправників зі списку дозволу):** деякі команди також працюють, коли вони вбудовані у звичайне повідомлення, і вилучаються до того, як модель побачить решту тексту.
|
||||
- Приклад: `hey /status` запускає відповідь зі статусом, а решта тексту продовжує проходити звичайним потоком.
|
||||
- **Швидкий шлях:** повідомлення лише з командами від відправників зі списку дозволених обробляються негайно (в обхід черги й моделі).
|
||||
- **Обмеження згадкою в групі:** повідомлення лише з командами від відправників зі списку дозволених обходять вимоги щодо згадки.
|
||||
- **Вбудовані скорочення (лише для відправників зі списку дозволених):** деякі команди також працюють, коли вбудовані в звичайне повідомлення, і видаляються до того, як модель побачить решту тексту.
|
||||
- Приклад: `hey /status` запускає відповідь зі статусом, а решта тексту проходить звичайним шляхом.
|
||||
- Наразі: `/help`, `/commands`, `/status`, `/whoami` (`/id`).
|
||||
- Неавторизовані повідомлення лише з командами мовчки ігноруються, а вбудовані токени `/...` трактуються як звичайний текст.
|
||||
- Неавторизовані повідомлення лише з командами мовчки ігноруються, а вбудовані токени `/...` обробляються як звичайний текст.
|
||||
</Accordion>
|
||||
<Accordion title="Команди skill-ів і аргументи нативних команд">
|
||||
- **Команди skill-ів:** skills типу `user-invocable` доступні як слеш-команди. Імена нормалізуються до `a-z0-9_` (макс. 32 символи); у разі колізій додаються числові суфікси (наприклад, `_2`).
|
||||
- `/skill <name> [input]` запускає skill за назвою (корисно, коли обмеження нативних команд не дозволяють мати окрему команду для кожного skill-а).
|
||||
- За замовчуванням команди skill-ів пересилаються моделі як звичайний запит.
|
||||
- Skills можуть за бажанням оголосити `command-dispatch: tool`, щоб маршрутизувати команду безпосередньо до інструмента (детерміновано, без моделі).
|
||||
- Приклад: `/prose` (plugin OpenProse) — див. [OpenProse](/uk/prose).
|
||||
- **Аргументи нативних команд:** Discord використовує автодоповнення для динамічних параметрів (і кнопкові меню, коли ви пропускаєте обов’язкові аргументи). Telegram і Slack показують кнопкове меню, коли команда підтримує варіанти вибору, а ви пропускаєте аргумент. Динамічні варіанти вибору визначаються відносно моделі цільової сесії, тож параметри, залежні від моделі, як-от рівні `/think`, слідують за перевизначенням `/model` цієї сесії.
|
||||
<Accordion title="Команди Skill і аргументи нативних команд">
|
||||
- **Команди Skill:** Skills із `user-invocable` доступні як slash-команди. Назви санітизуються до `a-z0-9_` (максимум 32 символи); для колізій додаються числові суфікси (наприклад, `_2`).
|
||||
- `/skill <name> [input]` запускає Skill за назвою (корисно, коли обмеження нативних команд не дозволяють мати окрему команду для кожного Skill).
|
||||
- За замовчуванням команди Skill пересилаються моделі як звичайний запит.
|
||||
- Skills можуть за бажанням оголошувати `command-dispatch: tool`, щоб маршрутизувати команду безпосередньо до інструмента (детерміновано, без моделі).
|
||||
- Приклад: `/prose` (плагін OpenProse) — див. [OpenProse](/uk/prose).
|
||||
- **Аргументи нативних команд:** Discord використовує автодоповнення для динамічних параметрів (і меню кнопок, коли ви пропускаєте обов’язкові аргументи). Telegram і Slack показують меню кнопок, коли команда підтримує варіанти, а ви пропускаєте аргумент. Динамічні варіанти визначаються відносно цільової моделі сеансу, тому специфічні для моделі параметри, як-от рівні `/think`, дотримуються перевизначення `/model` цього сеансу.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## `/tools`
|
||||
|
||||
`/tools` відповідає на питання про середовище виконання, а не про конфігурацію: **чим цей агент може користуватися прямо зараз у цій розмові**.
|
||||
`/tools` відповідає на запитання про середовище виконання, а не про конфігурацію: **що цей агент може використовувати прямо зараз у цій розмові**.
|
||||
|
||||
- Типове `/tools` є компактним і оптимізованим для швидкого перегляду.
|
||||
- Типовий `/tools` — компактний і оптимізований для швидкого перегляду.
|
||||
- `/tools verbose` додає короткі описи.
|
||||
- Поверхні з нативними командами, які підтримують аргументи, надають той самий перемикач режимів `compact|verbose`.
|
||||
- Результати прив’язані до сесії, тому зміна агента, каналу, треду, авторизації відправника або моделі може змінити вивід.
|
||||
- `/tools` включає інструменти, які реально доступні під час виконання, зокрема core-інструменти, інструменти під’єднаних plugin-ів і інструменти, що належать каналу.
|
||||
- Поверхні з нативними командами, які підтримують аргументи, надають той самий перемикач режиму `compact|verbose`.
|
||||
- Результати прив’язані до сеансу, тому зміна агента, каналу, гілки, авторизації відправника або моделі може змінити вивід.
|
||||
- `/tools` включає інструменти, які справді доступні під час виконання, зокрема базові інструменти, інструменти підключених плагінів і інструменти, що належать каналу.
|
||||
|
||||
Для редагування профілів і перевизначень використовуйте панель Tools у Control UI або поверхні конфігурації/каталогу, а не сприймайте `/tools` як статичний каталог.
|
||||
Для редагування профілів і перевизначень використовуйте панель Tools у Control UI або поверхні конфігурації/каталогу, а не розглядайте `/tools` як статичний каталог.
|
||||
|
||||
## Поверхні використання (що де показується)
|
||||
|
||||
- **Використання/квота провайдера** (наприклад, "Claude 80% left") відображається в `/status` для провайдера поточної моделі, коли ввімкнено відстеження використання. OpenClaw нормалізує вікна провайдерів до `% left`; для MiniMax поля відсотка лише залишку інвертуються перед показом, а відповіді `model_remains` віддають перевагу запису chat-моделі разом із міткою плану, позначеною моделлю.
|
||||
- **Рядки токенів/кешу** в `/status` можуть повертатися до останнього запису використання transcript-а, якщо живий знімок сесії неповний. Наявні ненульові живі значення все одно мають пріоритет, а резервне використання transcript-а також може відновити мітку активної моделі середовища виконання та більший сумарний обсяг, орієнтований на prompt, коли збережені підсумки відсутні або менші.
|
||||
- **Execution проти Runtime:** `/status` повідомляє `Execution` для ефективного шляху sandbox і `Runtime` для того, хто фактично виконує сесію: `OpenClaw Pi Default`, `OpenAI Codex`, CLI backend або ACP backend.
|
||||
- **Використання/квота провайдера** (приклад: "Claude 80% left") з’являється в `/status` для поточного провайдера моделі, коли відстеження використання ввімкнено. OpenClaw нормалізує вікна провайдерів до `% left`; для MiniMax поля відсотка, що містять лише залишок, інвертуються перед показом, а відповіді `model_remains` надають перевагу запису chat-model плюс мітці тарифного плану з тегом моделі.
|
||||
- **Рядки токенів/кешу** в `/status` можуть повертатися до останнього запису використання transcript, коли живий знімок сеансу розріджений. Наявні ненульові живі значення все одно мають пріоритет, а fallback до transcript також може відновити мітку активної моделі середовища виконання плюс більший загальний показник, орієнтований на prompt, коли збережені підсумки відсутні або менші.
|
||||
- **Execution проти runtime:** `/status` повідомляє `Execution` для ефективного шляху sandbox і `Runtime` для того, хто фактично виконує сеанс: `OpenClaw Pi Default`, `OpenAI Codex`, CLI backend або ACP backend.
|
||||
- **Токени/вартість для кожної відповіді** керуються через `/usage off|tokens|full` (додаються до звичайних відповідей).
|
||||
- `/model status` стосується **моделей/auth/ендпоінтів**, а не використання.
|
||||
- `/model status` стосується **моделей/автентифікації/endpoints**, а не використання.
|
||||
|
||||
## Вибір моделі (`/model`)
|
||||
|
||||
@ -314,14 +316,14 @@ Skills, які може викликати користувач, також до
|
||||
|
||||
Нотатки:
|
||||
|
||||
- `/model` і `/model list` показують компактний нумерований вибір (сімейство моделей + доступні провайдери).
|
||||
- У Discord `/model` і `/models` відкривають інтерактивний засіб вибору з випадними списками провайдерів і моделей, а також кроком Submit.
|
||||
- `/model` і `/model list` показують компактний, пронумерований засіб вибору (сімейство моделей + доступні провайдери).
|
||||
- У Discord `/model` і `/models` відкривають інтерактивний засіб вибору зі спадними списками провайдера й моделі та кроком Submit.
|
||||
- `/model <#>` вибирає з цього засобу вибору (і за можливості надає перевагу поточному провайдеру).
|
||||
- `/model status` показує докладний вигляд, зокрема налаштований ендпоінт провайдера (`baseUrl`) і режим API (`api`), якщо доступно.
|
||||
- `/model status` показує докладний вигляд, зокрема налаштований endpoint провайдера (`baseUrl`) і режим API (`api`), якщо доступно.
|
||||
|
||||
## Перевизначення налагодження
|
||||
|
||||
`/debug` дає змогу задавати перевизначення конфігурації **лише під час виконання** (пам’ять, не диск). Лише для власника. За замовчуванням вимкнено; увімкніть через `commands.debug: true`.
|
||||
`/debug` дає змогу задавати **перевизначення конфігурації лише під час виконання** (пам’ять, не диск). Лише для власника. Типово вимкнено; увімкніть через `commands.debug: true`.
|
||||
|
||||
Приклади:
|
||||
|
||||
@ -337,9 +339,9 @@ Skills, які може викликати користувач, також до
|
||||
Перевизначення застосовуються негайно до нових читань конфігурації, але **не** записуються в `openclaw.json`. Використовуйте `/debug reset`, щоб очистити всі перевизначення й повернутися до конфігурації на диску.
|
||||
</Note>
|
||||
|
||||
## Вивід trace plugin-ів
|
||||
## Вивід trace плагіна
|
||||
|
||||
`/trace` дає змогу перемикати **рядки trace/debug plugin-ів у межах сесії** без увімкнення повного verbose-режиму.
|
||||
`/trace` дає змогу перемикати **рядки trace/debug плагіна в межах сеансу** без увімкнення повного verbose-режиму.
|
||||
|
||||
Приклади:
|
||||
|
||||
@ -351,16 +353,16 @@ Skills, які може викликати користувач, також до
|
||||
|
||||
Нотатки:
|
||||
|
||||
- `/trace` без аргументу показує поточний стан trace для сесії.
|
||||
- `/trace on` вмикає рядки trace plugin-ів для поточної сесії.
|
||||
- `/trace` без аргументу показує поточний стан trace для сеансу.
|
||||
- `/trace on` вмикає рядки trace плагіна для поточного сеансу.
|
||||
- `/trace off` знову їх вимикає.
|
||||
- Рядки trace plugin-ів можуть з’являтися в `/status` і як додаткове діагностичне повідомлення після звичайної відповіді асистента.
|
||||
- `/trace` не замінює `/debug`; `/debug` як і раніше керує перевизначеннями конфігурації лише під час виконання.
|
||||
- `/trace` не замінює `/verbose`; звичайний докладний вивід інструментів/статусу все ще належить до `/verbose`.
|
||||
- Рядки trace плагіна можуть з’являтися в `/status` і як додаткове діагностичне повідомлення після звичайної відповіді асистента.
|
||||
- `/trace` не замінює `/debug`; `/debug` і далі керує перевизначеннями конфігурації лише під час виконання.
|
||||
- `/trace` не замінює `/verbose`; звичайний докладний вивід інструментів/статусу все ще належить `/verbose`.
|
||||
|
||||
## Оновлення конфігурації
|
||||
|
||||
`/config` записує у вашу конфігурацію на диску (`openclaw.json`). Лише для власника. За замовчуванням вимкнено; увімкніть через `commands.config: true`.
|
||||
`/config` записує у вашу конфігурацію на диску (`openclaw.json`). Лише для власника. Типово вимкнено; увімкніть через `commands.config: true`.
|
||||
|
||||
Приклади:
|
||||
|
||||
@ -373,12 +375,12 @@ Skills, які може викликати користувач, також до
|
||||
```
|
||||
|
||||
<Note>
|
||||
Перед записом конфігурація проходить валідацію; неприпустимі зміни відхиляються. Оновлення `/config` зберігаються після перезапуску.
|
||||
Перед записом конфігурація проходить перевірку; недійсні зміни відхиляються. Оновлення `/config` зберігаються після перезапуску.
|
||||
</Note>
|
||||
|
||||
## Оновлення MCP
|
||||
|
||||
`/mcp` записує визначення серверів MCP, якими керує OpenClaw, у `mcp.servers`. Лише для власника. За замовчуванням вимкнено; увімкніть через `commands.mcp: true`.
|
||||
`/mcp` записує визначення MCP-серверів, якими керує OpenClaw, у `mcp.servers`. Лише для власника. Типово вимкнено; увімкніть через `commands.mcp: true`.
|
||||
|
||||
Приклади:
|
||||
|
||||
@ -390,12 +392,12 @@ Skills, які може викликати користувач, також до
|
||||
```
|
||||
|
||||
<Note>
|
||||
`/mcp` зберігає конфігурацію в конфігурації OpenClaw, а не в налаштуваннях проєкту, якими володіє Pi. Адаптери середовища виконання вирішують, які транспорти реально можна виконувати.
|
||||
`/mcp` зберігає конфігурацію в конфігурації OpenClaw, а не в налаштуваннях проєкту, якими володіє Pi. Адаптери середовища виконання вирішують, які транспорти справді можна виконати.
|
||||
</Note>
|
||||
|
||||
## Оновлення plugin-ів
|
||||
## Оновлення плагінів
|
||||
|
||||
`/plugins` дає операторам змогу перевіряти виявлені plugin-и та перемикати їх увімкнення в конфігурації. Для сценаріїв лише читання можна використовувати `/plugin` як псевдонім. За замовчуванням вимкнено; увімкніть через `commands.plugins: true`.
|
||||
`/plugins` дає змогу операторам перевіряти виявлені плагіни й перемикати стан увімкнення в конфігурації. Для сценаріїв лише читання можна використовувати `/plugin` як псевдонім. Типово вимкнено; увімкніть через `commands.plugins: true`.
|
||||
|
||||
Приклади:
|
||||
|
||||
@ -408,41 +410,41 @@ Skills, які може викликати користувач, також до
|
||||
```
|
||||
|
||||
<Note>
|
||||
- `/plugins list` і `/plugins show` використовують реальне виявлення plugin-ів у поточному робочому просторі разом із конфігурацією на диску.
|
||||
- `/plugins enable|disable` оновлює лише конфігурацію plugin-ів; воно не встановлює й не видаляє plugin-и.
|
||||
- `/plugins list` і `/plugins show` використовують реальне виявлення плагінів відносно поточного робочого простору та конфігурації на диску.
|
||||
- `/plugins enable|disable` оновлює лише конфігурацію плагіна; він не встановлює й не видаляє плагіни.
|
||||
- Після змін `enable/disable` перезапустіть gateway, щоб застосувати їх.
|
||||
</Note>
|
||||
|
||||
## Нотатки щодо поверхонь
|
||||
## Нотатки про поверхні
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Сесії для кожної поверхні">
|
||||
- **Текстові команди** виконуються у звичайній сесії чату (приватні повідомлення спільно використовують `main`, групи мають власну сесію).
|
||||
- **Нативні команди** використовують ізольовані сесії:
|
||||
<Accordion title="Сеанси для кожної поверхні">
|
||||
- **Текстові команди** виконуються у звичайному чат-сеансі (DM використовують спільний `main`, групи мають власний сеанс).
|
||||
- **Нативні команди** використовують ізольовані сеанси:
|
||||
- Discord: `agent:<agentId>:discord:slash:<userId>`
|
||||
- Slack: `agent:<agentId>:slack:slash:<userId>` (префікс налаштовується через `channels.slack.slashCommand.sessionPrefix`)
|
||||
- Telegram: `telegram:slash:<userId>` (націлюється на сесію чату через `CommandTargetSessionKey`)
|
||||
- **`/stop`** націлюється на активну сесію чату, щоб можна було перервати поточний запуск.
|
||||
- Slack: `agent:<agentId>:slack:slash:<userId>` (префікс можна налаштувати через `channels.slack.slashCommand.sessionPrefix`)
|
||||
- Telegram: `telegram:slash:<userId>` (націлюється на чат-сеанс через `CommandTargetSessionKey`)
|
||||
- **`/stop`** націлюється на активний чат-сеанс, щоб можна було перервати поточний запуск.
|
||||
</Accordion>
|
||||
<Accordion title="Особливості Slack">
|
||||
`channels.slack.slashCommand` усе ще підтримується для однієї команди у стилі `/openclaw`. Якщо ви вмикаєте `commands.native`, потрібно створити одну слеш-команду Slack для кожної вбудованої команди (з тими самими назвами, що й у `/help`). Меню аргументів команд для Slack доставляються як ефемерні кнопки Block Kit.
|
||||
`channels.slack.slashCommand` досі підтримується для однієї команди у стилі `/openclaw`. Якщо ви вмикаєте `commands.native`, потрібно створити одну slash-команду Slack для кожної вбудованої команди (з тими самими назвами, що й у `/help`). Меню аргументів команд для Slack доставляються як ефемерні кнопки Block Kit.
|
||||
|
||||
Виняток для нативних команд Slack: реєструйте `/agentstatus` (а не `/status`), оскільки Slack резервує `/status`. Текстова команда `/status` у повідомленнях Slack усе одно працює.
|
||||
Виняток для нативних команд Slack: реєструйте `/agentstatus` (а не `/status`), тому що Slack резервує `/status`. Текстова `/status` у повідомленнях Slack усе одно працює.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Побічні запитання BTW
|
||||
|
||||
`/btw` — це швидке **побічне запитання** щодо поточної сесії.
|
||||
`/btw` — це швидке **побічне запитання** щодо поточного сеансу.
|
||||
|
||||
На відміну від звичайного чату:
|
||||
|
||||
- воно використовує поточну сесію як фоновий контекст,
|
||||
- виконується як окремий одноразовий виклик **без інструментів**,
|
||||
- не змінює майбутній контекст сесії,
|
||||
- не записується в історію transcript,
|
||||
- доставляється як живий побічний результат, а не як звичайне повідомлення асистента.
|
||||
- воно використовує поточний сеанс як фоновий контекст,
|
||||
- воно виконується як окремий одноразовий виклик **без інструментів**,
|
||||
- воно не змінює майбутній контекст сеансу,
|
||||
- воно не записується в історію transcript,
|
||||
- воно доставляється як живий побічний результат, а не як звичайне повідомлення асистента.
|
||||
|
||||
Це робить `/btw` корисним, коли вам потрібне тимчасове уточнення, поки основне завдання триває.
|
||||
|
||||
@ -452,10 +454,10 @@ Skills, які може викликати користувач, також до
|
||||
/btw what are we doing right now?
|
||||
```
|
||||
|
||||
Див. [BTW Side Questions](/uk/tools/btw) для повного опису поведінки та деталей UX клієнта.
|
||||
Див. [BTW Side Questions](/uk/tools/btw), щоб дізнатися повну поведінку та подробиці UX клієнта.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Створення skill-ів](/uk/tools/creating-skills)
|
||||
- [Створення Skills](/uk/tools/creating-skills)
|
||||
- [Skills](/uk/tools/skills)
|
||||
- [Конфігурація Skills](/uk/tools/skills-config)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user