Manifest Pluginu

Ta strona dotyczy wyłącznie natywnego manifestu Plugin OpenClaw.

Zgodne układy pakietów opisuje strona Pakiety Plugin.

Zgodne formaty pakietów używają innych plików manifestu:

• Pakiet Codex: .codex-plugin/plugin.json
• Pakiet Claude: .claude-plugin/plugin.json albo domyślny układ komponentów Claude bez manifestu
• Pakiet Cursor: .cursor-plugin/plugin.json

OpenClaw automatycznie wykrywa również te układy pakietów, ale nie są one walidowane względem schematu openclaw.plugin.json opisanego tutaj.

W przypadku zgodnych pakietów OpenClaw obecnie odczytuje metadane pakietu oraz zadeklarowane katalogi główne skill, katalogi główne poleceń Claude, wartości domyślne settings.json pakietu Claude, wartości domyślne LSP pakietu Claude oraz obsługiwane pakiety hooków, gdy układ jest zgodny z oczekiwaniami runtime OpenClaw.

Każdy natywny Plugin OpenClaw musi dostarczać plik openclaw.plugin.json w katalogu głównym Plugin. OpenClaw używa tego manifestu do walidacji konfiguracji bez wykonywania kodu Plugin. Brakujące lub nieprawidłowe manifesty są traktowane jako błędy Plugin i blokują walidację konfiguracji.

Zobacz pełny przewodnik po systemie Plugin: Pluginy. Natywny model możliwości i aktualne wskazówki dotyczące zgodności zewnętrznej: Model możliwości.

Do czego służy ten plik

openclaw.plugin.json to metadane, które OpenClaw odczytuje zanim załaduje kod Plugin. Wszystko poniżej musi być wystarczająco tanie do sprawdzenia bez uruchamiania runtime Plugin.

Używaj go do:

• tożsamości Plugin, walidacji konfiguracji i wskazówek interfejsu konfiguracji
• metadanych uwierzytelniania, onboardingu i konfiguracji początkowej (alias, automatyczne włączanie, zmienne środowiskowe dostawcy, wybory uwierzytelniania)
• wskazówek aktywacji dla powierzchni płaszczyzny sterowania
• skróconej własności rodzin modeli
• statycznych migawek własności możliwości (contracts)
• metadanych runnera QA, które współdzielony host openclaw qa może sprawdzić
• metadanych konfiguracji specyficznych dla kanału, scalanych z katalogiem i powierzchniami walidacji

Nie używaj go do: rejestrowania zachowania runtime, deklarowania punktów wejścia kodu ani metadanych instalacji npm. Te elementy należą do kodu Plugin i pliku package.json.

Minimalny przykład

{  "id": "voice-call",  "configSchema": {    "type": "object",    "additionalProperties": false,    "properties": {}  }}

Rozbudowany przykład

{  "id": "openrouter",  "name": "OpenRouter",  "description": "OpenRouter provider plugin",  "version": "1.0.0",  "providers": ["openrouter"],  "modelSupport": {    "modelPrefixes": ["router-"]  },  "modelIdNormalization": {    "providers": {      "openrouter": {        "prefixWhenBare": "openrouter"      }    }  },  "providerEndpoints": [    {      "endpointClass": "openrouter",      "hostSuffixes": ["openrouter.ai"]    }  ],  "providerRequest": {    "providers": {      "openrouter": {        "family": "openrouter"      }    }  },  "cliBackends": ["openrouter-cli"],  "syntheticAuthRefs": ["openrouter-cli"],  "setup": {    "providers": [      {        "id": "openrouter",        "envVars": ["OPENROUTER_API_KEY"]      }    ]  },  "providerAuthAliases": {    "openrouter-coding": "openrouter"  },  "channelEnvVars": {    "openrouter-chatops": ["OPENROUTER_CHATOPS_TOKEN"]  },  "providerAuthChoices": [    {      "provider": "openrouter",      "method": "api-key",      "choiceId": "openrouter-api-key",      "choiceLabel": "OpenRouter API key",      "groupId": "openrouter",      "groupLabel": "OpenRouter",      "optionKey": "openrouterApiKey",      "cliFlag": "--openrouter-api-key",      "cliOption": "--openrouter-api-key <key>",      "cliDescription": "OpenRouter API key",      "onboardingScopes": ["text-inference"]    }  ],  "uiHints": {    "apiKey": {      "label": "API key",      "placeholder": "sk-or-v1-...",      "sensitive": true    }  },  "configSchema": {    "type": "object",    "additionalProperties": false,    "properties": {      "apiKey": {        "type": "string"      }    }  }}

Odniesienie do pól najwyższego poziomu

Dokumentacja referencyjna metadanych dostawcy generowania

Pola metadanych dostawcy generowania opisują statyczne sygnały uwierzytelniania dla dostawców zadeklarowanych na pasującej liście contracts.*GenerationProviders. OpenClaw odczytuje te pola przed załadowaniem runtime dostawcy, aby narzędzia rdzenia mogły zdecydować, czy dostawca generowania jest dostępny, bez importowania każdego Pluginu dostawcy.

Używaj tych pól tylko do tanich, deklaratywnych faktów. Transport, przekształcenia żądań, odświeżanie tokenów, walidacja poświadczeń i rzeczywiste zachowanie generowania pozostają w runtime Pluginu.

{  "contracts": {    "imageGenerationProviders": ["example-image"]  },  "imageGenerationProviderMetadata": {    "example-image": {      "aliases": ["example-image-oauth"],      "authProviders": ["example-image"],      "configSignals": [        {          "rootPath": "plugins.entries.example-image.config",          "overlayPath": "image",          "mode": {            "path": "mode",            "default": "local",            "allowed": ["local"]          },          "requiredAny": ["workflow", "workflowPath"],          "required": ["promptNodeId"]        }      ],      "authSignals": [        {          "provider": "example-image"        },        {          "provider": "example-image-oauth",          "providerBaseUrl": {            "provider": "example-image",            "defaultBaseUrl": "https://api.example.com/v1",            "allowedBaseUrls": ["https://api.example.com/v1"]          }        }      ]    }  }}

Każdy wpis metadanych obsługuje:

Każdy wpis configSignals obsługuje:

Każda blokada mode obsługuje:

Każdy wpis authSignals obsługuje:

Każda blokada providerBaseUrl obsługuje:

Dokumentacja referencyjna metadanych narzędzi

toolMetadata używa tych samych kształtów configSignals i authSignals co metadane dostawcy generowania, indeksowanych nazwą narzędzia. contracts.tools deklaruje własność. toolMetadata deklaruje tani dowód dostępności, aby OpenClaw mógł uniknąć importowania runtime Pluginu tylko po to, aby jego fabryka narzędzi zwróciła null.

{  "setup": {    "providers": [      {        "id": "example",        "envVars": ["EXAMPLE_API_KEY"]      }    ]  },  "contracts": {    "tools": ["example_search"]  },  "toolMetadata": {    "example_search": {      "authSignals": [        {          "provider": "example"        }      ],      "configSignals": [        {          "rootPath": "plugins.entries.example.config",          "overlayPath": "search",          "required": ["apiKey"]        }      ]    }  }}

Jeśli narzędzie nie ma toolMetadata, OpenClaw zachowuje istniejące zachowanie i ładuje właścicielski Plugin, gdy kontrakt narzędzia pasuje do zasad. Dla narzędzi na gorącej ścieżce, których fabryka zależy od uwierzytelniania/konfiguracji, autorzy Pluginów powinni deklarować toolMetadata zamiast sprawiać, by rdzeń importował runtime w celu zapytania.

Dokumentacja referencyjna providerAuthChoices

Każdy wpis providerAuthChoices opisuje jeden wybór onboardingu lub uwierzytelniania. OpenClaw odczytuje go przed załadowaniem runtime dostawcy. Listy konfiguracji dostawcy używają tych wyborów z manifestu, wyborów konfiguracji wyprowadzonych z deskryptora oraz metadanych katalogu instalacji bez ładowania runtime dostawcy.

Informacje referencyjne commandAliases

Użyj commandAliases, gdy plugin posiada nazwę polecenia środowiska uruchomieniowego, którą użytkownicy mogą omyłkowo umieścić w plugins.allow albo spróbować uruchomić jako główne polecenie CLI. OpenClaw używa tych metadanych do diagnostyki bez importowania kodu środowiska uruchomieniowego pluginu.

{  "commandAliases": [    {      "name": "dreaming",      "kind": "runtime-slash",      "cliCommand": "memory"    }  ]}

Informacje referencyjne activation

Użyj activation, gdy plugin może tanio zadeklarować, które zdarzenia płaszczyzny sterowania powinny uwzględniać go w planie aktywacji/ładowania.

Ten blok to metadane planisty, a nie API cyklu życia. Nie rejestruje zachowania środowiska uruchomieniowego, nie zastępuje register(...) i nie obiecuje, że kod pluginu już został wykonany. Planista aktywacji używa tych pól, aby zawęzić pluginy kandydujące przed użyciem istniejących metadanych własności z manifestu, takich jak providers, channels, commandAliases, setup.providers, contracts.tools i hooki.

Preferuj najwęższe metadane, które już opisują własność. Używaj providers, channels, commandAliases, deskryptorów konfiguracji lub contracts, gdy te pola wyrażają relację. Używaj activation dla dodatkowych wskazówek planisty, których nie da się przedstawić za pomocą tych pól własności. Używaj najwyższego poziomu cliBackends dla aliasów środowiska uruchomieniowego CLI, takich jak claude-cli, my-cli lub google-gemini-cli; activation.onAgentHarnesses służy tylko do osadzonych identyfikatorów harnessów agentów, które nie mają jeszcze pola własności.

Ten blok zawiera wyłącznie metadane. Nie rejestruje zachowania środowiska uruchomieniowego i nie zastępuje register(...), setupEntry ani innych punktów wejścia środowiska uruchomieniowego/pluginu. Obecni konsumenci używają go jako wskazówki zawężającej przed szerszym ładowaniem pluginów, więc brak metadanych aktywacji niezwiązanych ze startem zwykle kosztuje tylko wydajność; nie powinien zmieniać poprawności, dopóki nadal istnieją awaryjne mechanizmy własności manifestu.

Każdy plugin powinien świadomie ustawić activation.onStartup. Ustaw go na true tylko wtedy, gdy plugin musi działać podczas startu Gateway. Ustaw go na false, gdy plugin jest bezczynny przy starcie i powinien ładować się tylko z węższych wyzwalaczy. Pominięcie onStartup nie powoduje już niejawnego ładowania pluginu przy starcie; użyj jawnych metadanych aktywacji dla startu, kanału, konfiguracji, harnessu agenta, pamięci lub innych węższych wyzwalaczy aktywacji.

{  "activation": {    "onStartup": false,    "onProviders": ["openai"],    "onCommands": ["models"],    "onChannels": ["web"],    "onRoutes": ["gateway-webhook"],    "onConfigPaths": ["browser"],    "onCapabilities": ["provider", "tool"]  }}

Obecni aktywni konsumenci:

• planowanie startu Gateway używa activation.onStartup do jawnego importu przy starcie
• planowanie CLI wyzwalane poleceniem używa awaryjnie starszych commandAliases[].cliCommand lub commandAliases[].name
• planowanie startu środowiska uruchomieniowego agenta używa activation.onAgentHarnesses dla osadzonych harnessów oraz najwyższego poziomu cliBackends[] dla aliasów środowiska uruchomieniowego CLI
• planowanie konfiguracji/kanału wyzwalane kanałem używa awaryjnie starszej własności channels[], gdy brakuje jawnych metadanych aktywacji kanału
• planowanie pluginów przy starcie używa activation.onConfigPaths dla niekanałowych głównych powierzchni konfiguracji, takich jak blok browser dołączonego pluginu przeglądarki
• planowanie konfiguracji/środowiska uruchomieniowego wyzwalane providerem używa awaryjnie starszej własności providers[] i najwyższego poziomu cliBackends[], gdy brakuje jawnych metadanych aktywacji providera

Diagnostyka planisty może odróżniać jawne wskazówki aktywacji od awaryjnej własności manifestu. Na przykład activation-command-hint oznacza, że dopasowano activation.onCommands, podczas gdy manifest-command-alias oznacza, że planista użył zamiast tego własności commandAliases. Te etykiety powodów są przeznaczone dla diagnostyki hosta i testów; autorzy pluginów powinni nadal deklarować metadane, które najlepiej opisują własność.

Informacje referencyjne qaRunners

Użyj qaRunners, gdy plugin wnosi jeden lub więcej runnerów transportu pod wspólny katalog główny openclaw qa. Utrzymuj te metadane jako tanie i statyczne; środowisko uruchomieniowe pluginu nadal posiada właściwą rejestrację CLI przez lekką powierzchnię runtime-api.ts, która eksportuje qaRunnerCliRegistrations.

{  "qaRunners": [    {      "commandName": "matrix",      "description": "Run the Docker-backed Matrix live QA lane against a disposable homeserver"    }  ]}

odniesienie setup

Użyj setup, gdy powierzchnie konfiguracji i wdrażania użytkownika potrzebują tanich metadanych należących do pluginu, zanim runtime zostanie załadowany.

{  "setup": {    "providers": [      {        "id": "openai",        "authMethods": ["api-key"],        "envVars": ["OPENAI_API_KEY"],        "authEvidence": [          {            "type": "local-file-with-env",            "fileEnvVar": "OPENAI_CREDENTIALS_FILE",            "requiresAllEnv": ["OPENAI_PROJECT"],            "credentialMarker": "openai-local-credentials",            "source": "openai local credentials"          }        ]      }    ],    "cliBackends": ["openai-cli"],    "configMigrations": ["legacy-openai-auth"],    "requiresRuntime": false  }}

Najwyższego poziomu cliBackends pozostaje prawidłowe i nadal opisuje backendy wnioskowania CLI. setup.cliBackends to powierzchnia deskryptorów specyficzna dla konfiguracji dla przepływów płaszczyzny sterowania/konfiguracji, które powinny pozostać wyłącznie metadanymi.

Gdy są obecne, setup.providers i setup.cliBackends są preferowaną powierzchnią wyszukiwania opartą najpierw na deskryptorach do wykrywania konfiguracji. Jeśli deskryptor tylko zawęża kandydujący plugin, a konfiguracja nadal potrzebuje bogatszych hooków runtime w czasie konfiguracji, ustaw requiresRuntime: true i pozostaw setup-api jako zapasową ścieżkę wykonania.

OpenClaw uwzględnia też setup.providers[].envVars w ogólnych wyszukiwaniach uwierzytelniania dostawcy i zmiennych środowiskowych. providerAuthEnvVars pozostaje obsługiwane przez adapter zgodności w oknie wycofywania, ale pluginy spoza pakietu, które nadal go używają, otrzymują diagnostykę manifestu. Nowe pluginy powinny umieszczać metadane zmiennych środowiskowych konfiguracji/statusu w setup.providers[].envVars.

OpenClaw może też wyprowadzać proste wybory konfiguracji z setup.providers[].authMethods, gdy wpis konfiguracji nie jest dostępny albo gdy setup.requiresRuntime: false deklaruje, że runtime konfiguracji nie jest potrzebny. Jawne wpisy providerAuthChoices pozostają preferowane dla niestandardowych etykiet, flag CLI, zakresu wdrażania użytkownika i metadanych asystenta.

Ustaw requiresRuntime: false tylko wtedy, gdy te deskryptory są wystarczające dla powierzchni konfiguracji. OpenClaw traktuje jawne false jako kontrakt wyłącznie deskryptorowy i nie wykona setup-api ani openclaw.setupEntry na potrzeby wyszukiwania konfiguracji. Jeśli plugin wyłącznie deskryptorowy nadal dostarcza jeden z tych wpisów runtime konfiguracji, OpenClaw zgłasza diagnostykę addytywną i nadal go ignoruje. Pominięte requiresRuntime zachowuje starsze zachowanie zapasowe, aby istniejące pluginy, które dodały deskryptory bez tej flagi, nie przestały działać.

Ponieważ wyszukiwanie konfiguracji może wykonywać kod setup-api należący do pluginu, znormalizowane wartości setup.providers[].id i setup.cliBackends[] muszą pozostać unikatowe wśród wykrytych pluginów. Niejednoznaczna własność kończy się zamknięciem z błędem zamiast wybierania zwycięzcy według kolejności wykrywania.

Gdy runtime konfiguracji jest wykonywany, diagnostyka rejestru konfiguracji zgłasza rozjazd deskryptorów, jeśli setup-api rejestruje dostawcę lub backend CLI, którego deskryptory manifestu nie deklarują, albo jeśli deskryptor nie ma pasującej rejestracji runtime. Te diagnostyki są addytywne i nie odrzucają starszych pluginów.

odniesienie setup.providers

authEvidence jest przeznaczone dla należących do dostawcy lokalnych znaczników poświadczeń, które można zweryfikować bez ładowania kodu runtime. Te kontrole muszą pozostać tanie i lokalne: bez wywołań sieciowych, bez odczytów z pęku kluczy ani menedżera sekretów, bez poleceń powłoki i bez prób API dostawcy.

Obsługiwane wpisy dowodów:

pola setup

odniesienie uiHints

uiHints to mapa od nazw pól konfiguracji do małych wskazówek renderowania.

{  "uiHints": {    "apiKey": {      "label": "API key",      "help": "Used for OpenRouter requests",      "placeholder": "sk-or-v1-...",      "sensitive": true    }  }}

Każda wskazówka pola może zawierać:

odniesienie contracts

Używaj contracts tylko dla statycznych metadanych własności funkcjonalności, które OpenClaw może odczytać bez importowania runtime pluginu.

{  "contracts": {    "agentToolResultMiddleware": ["openclaw", "codex"],    "trustedToolPolicies": ["workflow-budget"],    "externalAuthProviders": ["acme-ai"],    "embeddingProviders": ["openai-compatible"],    "speechProviders": ["openai"],    "realtimeTranscriptionProviders": ["openai"],    "realtimeVoiceProviders": ["openai"],    "memoryEmbeddingProviders": ["local"],    "mediaUnderstandingProviders": ["openai"],    "imageGenerationProviders": ["openai"],    "videoGenerationProviders": ["qwen"],    "webFetchProviders": ["firecrawl"],    "webSearchProviders": ["gemini"],    "migrationProviders": ["hermes"],    "gatewayMethodDispatch": ["authenticated-request"],    "tools": ["firecrawl_search", "firecrawl_scrape"]  }}

Każda lista jest opcjonalna:

contracts.embeddedExtensionFactories pozostaje zachowane dla wbudowanych fabryk rozszerzeń wyłącznie dla serwera aplikacji Codex. Wbudowane transformacje wyników narzędzi powinny zamiast tego deklarować contracts.agentToolResultMiddleware i rejestrować się przez api.registerAgentToolResultMiddleware(...). Zainstalowane plugins mogą używać tego samego punktu integracji middleware tylko wtedy, gdy jest jawnie włączony, i tylko dla środowisk uruchomieniowych deklarowanych w contracts.agentToolResultMiddleware.

Zainstalowane plugins, które potrzebują hostowego zaufanego poziomu polityki przed użyciem narzędzia, muszą zadeklarować każdy zarejestrowany lokalny identyfikator w contracts.trustedToolPolicies i być jawnie włączone. Wbudowane plugins zachowują istniejącą ścieżkę zaufanych polityk, ale zainstalowane plugins z niezadeklarowanymi identyfikatorami polityk są odrzucane przed rejestracją. Identyfikatory polityk są ograniczone do rejestrującego pluginu, więc dwa plugins mogą jednocześnie zadeklarować i zarejestrować workflow-budget; pojedynczy plugin nie może zarejestrować tego samego lokalnego identyfikatora dwa razy.

Rejestracje środowiska uruchomieniowego api.registerTool(...) muszą odpowiadać contracts.tools. Wykrywanie narzędzi używa tej listy, aby ładować tylko te środowiska uruchomieniowe pluginów, które mogą być właścicielami żądanych narzędzi.

Plugins dostawców implementujące resolveExternalAuthProfiles powinny deklarować contracts.externalAuthProviders; niezadeklarowane hooki uwierzytelniania zewnętrznego są ignorowane.

Ogólni dostawcy embeddingów powinni deklarować contracts.embeddingProviders dla każdego adaptera zarejestrowanego przez api.registerEmbeddingProvider(...). Używaj ogólnego kontraktu do wielokrotnego generowania wektorów, w tym dla dostawców używanych przez wyszukiwanie w pamięci. contracts.memoryEmbeddingProviders to przestarzała zgodność specyficzna dla pamięci i pozostaje tylko na czas migracji istniejących dostawców do ogólnego punktu integracji dostawcy embeddingów.

contracts.gatewayMethodDispatch obecnie akceptuje "authenticated-request". Jest to bramka higieny API dla natywnych tras HTTP pluginu, które celowo wysyłają metody płaszczyzny sterowania Gateway w ramach procesu, a nie piaskownica przeciwko złośliwym natywnym plugins. Używaj jej tylko dla ściśle przejrzanych wbudowanych lub operatorskich powierzchni, które już wymagają uwierzytelniania HTTP Gateway.

Referencja mediaUnderstandingProviderMetadata

Użyj mediaUnderstandingProviderMetadata, gdy dostawca rozumienia mediów ma modele domyślne, priorytet awaryjnego automatycznego uwierzytelniania lub natywną obsługę dokumentów, których ogólne pomocniki rdzenia potrzebują przed załadowaniem środowiska uruchomieniowego. Klucze muszą być również zadeklarowane w contracts.mediaUnderstandingProviders.

{  "contracts": {    "mediaUnderstandingProviders": ["example"]  },  "mediaUnderstandingProviderMetadata": {    "example": {      "capabilities": ["image", "audio"],      "defaultModels": {        "image": "example-vision-latest",        "audio": "example-transcribe-latest"      },      "autoPriority": {        "image": 40      },      "nativeDocumentInputs": ["pdf"]    }  }}

Każdy wpis dostawcy może zawierać:

Referencja channelConfigs

Użyj channelConfigs, gdy plugin kanału potrzebuje tanich metadanych konfiguracji przed załadowaniem środowiska uruchomieniowego. Odczytowe wykrywanie konfiguracji/statusu kanału może używać tych metadanych bezpośrednio dla skonfigurowanych kanałów zewnętrznych, gdy nie ma dostępnego wpisu konfiguracji początkowej albo gdy setup.requiresRuntime: false deklaruje, że środowisko uruchomieniowe konfiguracji początkowej jest niepotrzebne.

channelConfigs to metadane manifestu pluginu, a nie nowa sekcja konfiguracji użytkownika najwyższego poziomu. Użytkownicy nadal konfigurują instancje kanałów w channels.<channel-id>. OpenClaw odczytuje metadane manifestu, aby zdecydować, który plugin jest właścicielem skonfigurowanego kanału, zanim kod środowiska uruchomieniowego pluginu zostanie wykonany.

Dla pluginu kanału configSchema i channelConfigs opisują różne ścieżki:

• configSchema waliduje plugins.entries.<plugin-id>.config
• channelConfigs.<channel-id>.schema waliduje channels.<channel-id>

Niewbudowane plugins deklarujące channels[] powinny również deklarować odpowiadające im wpisy channelConfigs. Bez nich OpenClaw nadal może załadować plugin, ale ścieżki zimne schematu konfiguracji, konfiguracji początkowej i Control UI nie mogą znać kształtu opcji należących do kanału, dopóki środowisko uruchomieniowe pluginu nie zostanie wykonane.

channelConfigs.<channel-id>.commands.nativeCommandsAutoEnabled i nativeSkillsAutoEnabled mogą deklarować statyczne wartości domyślne auto dla kontroli konfiguracji poleceń uruchamianych przed załadowaniem środowiska uruchomieniowego kanału. Wbudowane kanały mogą również publikować te same wartości domyślne przez package.json#openclaw.channel.commands obok innych metadanych katalogu kanałów należących do pakietu.

{  "channelConfigs": {    "matrix": {      "schema": {        "type": "object",        "additionalProperties": false,        "properties": {          "homeserverUrl": { "type": "string" }        }      },      "uiHints": {        "homeserverUrl": {          "label": "Homeserver URL",          "placeholder": "https://matrix.example.com"        }      },      "label": "Matrix",      "description": "Matrix homeserver connection",      "commands": {        "nativeCommandsAutoEnabled": true,        "nativeSkillsAutoEnabled": true      },      "preferOver": ["matrix-legacy"]    }  }}

Każdy wpis kanału może zawierać:

Zastępowanie innego pluginu kanału

Użyj preferOver, gdy Twój plugin jest preferowanym właścicielem identyfikatora kanału, który może również dostarczyć inny plugin. Typowe przypadki to zmieniona nazwa identyfikatora pluginu, samodzielny plugin zastępujący wbudowany plugin albo utrzymywany fork zachowujący ten sam identyfikator kanału dla zgodności konfiguracji.

{  "id": "acme-chat",  "channels": ["chat"],  "channelConfigs": {    "chat": {      "schema": {        "type": "object",        "additionalProperties": false,        "properties": {          "webhookUrl": { "type": "string" }        }      },      "preferOver": ["chat"]    }  }}

Gdy channels.chat jest skonfigurowane, OpenClaw bierze pod uwagę zarówno identyfikator kanału, jak i identyfikator preferowanego pluginu. Jeśli plugin o niższym priorytecie został wybrany tylko dlatego, że jest wbudowany albo domyślnie włączony, OpenClaw wyłącza go w efektywnej konfiguracji środowiska uruchomieniowego, aby jeden plugin był właścicielem kanału i jego narzędzi. Jawny wybór użytkownika nadal ma pierwszeństwo: jeśli użytkownik jawnie włącza oba plugins, OpenClaw zachowuje ten wybór i zgłasza diagnostykę zduplikowanych kanałów/narzędzi zamiast po cichu zmieniać żądany zestaw pluginów.

Ogranicz preferOver do identyfikatorów pluginów, które rzeczywiście mogą dostarczyć ten sam kanał. Nie jest to ogólne pole priorytetu i nie zmienia nazw kluczy konfiguracji użytkownika.

Referencja modelSupport

Użyj modelSupport, gdy OpenClaw ma wywnioskować Plugin dostawcy z krótkich identyfikatorów modeli, takich jak gpt-5.5 lub claude-sonnet-4.6, zanim załaduje się środowisko uruchomieniowe Pluginu.

{  "modelSupport": {    "modelPrefixes": ["gpt-", "o1", "o3", "o4"],    "modelPatterns": ["^computer-use-preview"]  }}

OpenClaw stosuje tę kolejność pierwszeństwa:

• jawne odwołania provider/model używają metadanych manifestu providers właściciela
• modelPatterns mają pierwszeństwo przed modelPrefixes
• jeśli pasują zarówno jeden Plugin niepakietowany, jak i jeden Plugin pakietowany, wygrywa Plugin niepakietowany
• pozostała niejednoznaczność jest ignorowana, dopóki użytkownik lub konfiguracja nie określi dostawcy

Pola:

Wpisy modelPatterns są kompilowane przez compileSafeRegex, który odrzuca wzorce zawierające zagnieżdżone powtórzenia (na przykład (a+)+$). Wzorce, które nie przejdą kontroli bezpieczeństwa, są po cichu pomijane, tak samo jak składniowo niepoprawny regex. Utrzymuj wzorce proste i unikaj zagnieżdżonych kwantyfikatorów.

Odwołanie modelCatalog

Użyj modelCatalog, gdy OpenClaw ma znać metadane modeli dostawcy przed załadowaniem środowiska uruchomieniowego Pluginu. To należące do manifestu źródło stałych wierszy katalogu, aliasów dostawców, reguł wyciszania i trybu odkrywania. Odświeżanie w środowisku uruchomieniowym nadal należy do kodu środowiska uruchomieniowego dostawcy, ale manifest informuje rdzeń, kiedy środowisko uruchomieniowe jest wymagane.

{  "providers": ["openai"],  "modelCatalog": {    "providers": {      "openai": {        "baseUrl": "https://api.openai.com/v1",        "api": "openai-responses",        "models": [          {            "id": "gpt-5.4",            "name": "GPT-5.4",            "input": ["text", "image"],            "reasoning": true,            "contextWindow": 256000,            "maxTokens": 128000,            "cost": {              "input": 1.25,              "output": 10,              "cacheRead": 0.125            },            "status": "available",            "tags": ["default"]          }        ]      }    },    "aliases": {      "azure-openai-responses": {        "provider": "openai",        "api": "azure-openai-responses"      }    },    "suppressions": [      {        "provider": "azure-openai-responses",        "model": "gpt-5.3-codex-spark",        "reason": "not available on Azure OpenAI Responses"      }    ],    "discovery": {      "openai": "static"    }  }}

Pola najwyższego poziomu:

aliases uczestniczy w wyszukiwaniu właściciela dostawcy na potrzeby planowania katalogu modeli. Cele aliasów muszą być dostawcami najwyższego poziomu należącymi do tego samego Pluginu. Gdy lista filtrowana według dostawcy używa aliasu, OpenClaw może odczytać manifest właściciela i zastosować nadpisania API/bazowego adresu URL aliasu bez ładowania środowiska uruchomieniowego dostawcy. Aliasy nie rozszerzają niefiltrowanych list katalogu; szerokie listy emitują tylko wiersze kanonicznego dostawcy właściciela.

suppressions zastępuje stary hook środowiska uruchomieniowego dostawcy suppressBuiltInModel. Wpisy wyciszeń są honorowane tylko wtedy, gdy dostawca należy do Pluginu lub jest zadeklarowany jako klucz modelCatalog.aliases, który wskazuje należącego dostawcę. Hooki wyciszania środowiska uruchomieniowego nie są już wywoływane podczas rozwiązywania modeli.

Pola dostawcy:

Pola modelu:

Pola wyciszeń:

Nie umieszczaj danych wyłącznie środowiska uruchomieniowego w modelCatalog. Używaj static tylko wtedy, gdy wiersze manifestu są wystarczająco kompletne, aby powierzchnie list i selektorów filtrowane według dostawcy mogły pominąć odkrywanie przez rejestr/środowisko uruchomieniowe. Używaj refreshable, gdy wiersze manifestu są użytecznymi listowalnymi ziarnami lub uzupełnieniami, ale odświeżenie/pamięć podręczna może później dodać więcej wierszy; wiersze odświeżalne same w sobie nie są autorytatywne. Używaj runtime, gdy OpenClaw musi załadować środowisko uruchomieniowe dostawcy, aby poznać listę.

Odwołanie modelIdNormalization

Użyj modelIdNormalization do taniego, należącego do dostawcy porządkowania identyfikatorów modeli, które musi nastąpić przed załadowaniem środowiska uruchomieniowego dostawcy. Dzięki temu aliasy, takie jak krótkie nazwy modeli, lokalne dla dostawcy starsze identyfikatory i reguły prefiksów proxy pozostają w manifeście właściwego Pluginu zamiast w tabelach wyboru modeli rdzenia.

{  "providers": ["anthropic", "openrouter"],  "modelIdNormalization": {    "providers": {      "anthropic": {        "aliases": {          "sonnet-4.6": "claude-sonnet-4-6"        }      },      "openrouter": {        "prefixWhenBare": "openrouter"      }    }  }}

Pola dostawcy:

Odwołanie providerEndpoints

Użyj providerEndpoints do klasyfikacji punktów końcowych, którą ogólna polityka żądań musi znać przed załadowaniem środowiska uruchomieniowego dostawcy. Rdzeń nadal jest właścicielem znaczenia każdego endpointClass; manifesty Pluginów są właścicielami metadanych hosta i bazowego adresu URL.

Pola endpointu:

Dokumentacja referencyjna providerRequest

Użyj providerRequest dla tanich metadanych zgodności żądań, których ogólna polityka żądań potrzebuje bez ładowania środowiska wykonawczego dostawcy. Przepisywanie ładunku specyficzne dla zachowania trzymaj w hakach środowiska wykonawczego dostawcy lub współdzielonych helperach rodziny dostawców.

{  "providers": ["vllm"],  "providerRequest": {    "providers": {      "vllm": {        "family": "vllm",        "openAICompletions": {          "supportsStreamingUsage": true        }      }    }  }}

Pola dostawcy:

Dokumentacja referencyjna secretProviderIntegrations

Użyj secretProviderIntegrations, gdy plugin może opublikować wielokrotnego użytku preset dostawcy exec SecretRef. OpenClaw odczytuje te metadane przed załadowaniem środowiska wykonawczego pluginu, zapisuje własność pluginu w secrets.providers.<alias>.pluginIntegration i pozostawia faktyczne rozwiązywanie sekretów środowisku wykonawczemu SecretRef. Presety są udostępniane tylko dla pluginów wbudowanych i zainstalowanych pluginów odkrytych z zarządzanych katalogów instalacji pluginów, takich jak instalacje git i ClawHub.

{  "secretProviderIntegrations": {    "secret-store": {      "providerAlias": "team-secrets",      "displayName": "Team secrets",      "source": "exec",      "command": "${node}",      "args": ["./bin/resolve-secrets.mjs"]    }  }}

Klucz mapy jest identyfikatorem integracji. Jeśli providerAlias zostanie pominięty, OpenClaw używa identyfikatora integracji jako aliasu dostawcy SecretRef. Aliasy dostawców muszą pasować do normalnego wzorca aliasu dostawcy SecretRef, na przykład team-secrets lub onepassword-work.

Gdy operator wybierze preset, OpenClaw zapisuje odwołanie do dostawcy takie jak:

{  "secrets": {    "providers": {      "team-secrets": {        "source": "exec",        "pluginIntegration": {          "pluginId": "acme-secrets",          "integrationId": "secret-store"        }      }    }  }}

Podczas uruchamiania lub ponownego ładowania OpenClaw rozwiązuje tego dostawcę, ładując bieżące metadane manifestu pluginu, sprawdzając, czy plugin właścicielski jest zainstalowany i aktywny, oraz materializując polecenie exec z manifestu. Wyłączenie lub usunięcie pluginu unieważnia dostawcę dla aktywnych SecretRefs. Operatorzy, którzy chcą samodzielnej konfiguracji exec, nadal mogą bezpośrednio zapisywać ręcznych dostawców command/args.

Obecnie obsługiwane są tylko presety source: "exec". command musi być ${node}, a args[0] musi być skryptem rozwiązywania względnym wobec katalogu głównego pluginu i zaczynającym się od ./. OpenClaw materializuje go podczas uruchamiania lub ponownego ładowania do bieżącego pliku wykonywalnego Node oraz bezwzględnej ścieżki skryptu w pluginie. Opcje Node, takie jak --require, --import, --loader, --env-file, --eval i --print, nie są częścią kontraktu presetu manifestu. Operatorzy, którzy potrzebują poleceń innych niż Node, mogą bezpośrednio skonfigurować samodzielnych ręcznych dostawców exec.

OpenClaw wyprowadza trustedDirs dla presetów manifestu z katalogu głównego pluginu oraz, dla presetów ${node}, z katalogu bieżącego pliku wykonywalnego Node. trustedDirs autorstwa manifestu są ignorowane. Inne opcje dostawcy exec, takie jak timeoutMs, maxOutputBytes, jsonOnly, env, passEnv i allowInsecurePath, przechodzą do normalnej konfiguracji dostawcy exec SecretRef.

Dokumentacja referencyjna modelPricing

Użyj modelPricing, gdy dostawca potrzebuje zachowania cenowego płaszczyzny sterowania przed załadowaniem środowiska wykonawczego. Pamięć podręczna cen Gateway odczytuje te metadane bez importowania kodu środowiska wykonawczego dostawcy.

{  "providers": ["ollama", "openrouter"],  "modelPricing": {    "providers": {      "ollama": {        "external": false      },      "openrouter": {        "openRouter": {          "passthroughProviderModel": true        },        "liteLLM": false      }    }  }}

Pola dostawcy:

Pola źródła:

Indeks dostawców OpenClaw

Indeks dostawców OpenClaw to metadane podglądowe należące do OpenClaw dla dostawców, których pluginy mogą nie być jeszcze zainstalowane. Nie jest częścią manifestu pluginu. Manifesty pluginów pozostają autorytetem zainstalowanego pluginu. Indeks dostawców jest wewnętrznym kontraktem awaryjnym, z którego przyszłe powierzchnie instalowalnych dostawców i selektora modeli przed instalacją będą korzystać, gdy plugin dostawcy nie jest zainstalowany.

Kolejność autorytetów katalogu:

1. Konfiguracja użytkownika.
2. Manifest zainstalowanego pluginu modelCatalog.
3. Pamięć podręczna katalogu modeli z jawnego odświeżenia.
4. Wiersze podglądu Indeksu dostawców OpenClaw.

Indeks dostawców nie może zawierać sekretów, stanu włączenia, haków środowiska wykonawczego ani aktywnych danych modeli specyficznych dla konta. Jego katalogi podglądowe używają tego samego kształtu wiersza dostawcy modelCatalog co manifesty pluginów, ale powinny pozostać ograniczone do stabilnych metadanych wyświetlania, chyba że pola adaptera środowiska wykonawczego, takie jak api, baseUrl, ceny lub flagi zgodności, są celowo utrzymywane w zgodności z manifestem zainstalowanego pluginu. Dostawcy z aktywnym odkrywaniem /models powinni zapisywać odświeżone wiersze przez jawną ścieżkę pamięci podręcznej katalogu modeli, zamiast wywoływać API dostawców podczas normalnego listowania lub onboardingu.

Wpisy Indeksu dostawców mogą także zawierać metadane instalowalnego pluginu dla dostawców, których plugin został przeniesiony poza rdzeń albo z innego powodu nie jest jeszcze zainstalowany. Te metadane odzwierciedlają wzorzec katalogu kanałów: nazwa pakietu, specyfikacja instalacji npm, oczekiwana integralność i tanie etykiety wyboru uwierzytelniania wystarczą, aby pokazać instalowalną opcję konfiguracji. Po zainstalowaniu pluginu wygrywa jego manifest, a wpis Indeksu dostawców jest ignorowany dla tego dostawcy.

Starsze klucze funkcjonalności najwyższego poziomu są przestarzałe. Użyj openclaw doctor --fix, aby przenieść speechProviders, realtimeTranscriptionProviders, realtimeVoiceProviders, mediaUnderstandingProviders, imageGenerationProviders, videoGenerationProviders, webFetchProviders i webSearchProviders pod contracts; normalne ładowanie manifestu nie traktuje już tych pól najwyższego poziomu jako własności funkcjonalności.

Manifest kontra package.json

Te dwa pliki pełnią różne zadania:

Jeśli nie masz pewności, gdzie należy dany element metadanych, użyj tej reguły:

• jeśli OpenClaw musi znać go przed załadowaniem kodu pluginu, umieść go w openclaw.plugin.json
• jeśli dotyczy pakowania, plików wejściowych lub zachowania instalacji npm, umieść go w package.json

Pola package.json wpływające na odkrywanie

Niektóre metadane pluginu sprzed uruchomienia celowo znajdują się w package.json w bloku openclaw, zamiast w openclaw.plugin.json. openclaw.bundle i openclaw.bundle.json nie są kontraktami pluginów OpenClaw; natywne pluginy muszą używać openclaw.plugin.json oraz obsługiwanych pól package.json#openclaw poniżej.

Ważne przykłady:

Metadane manifestu decydują, które wybory dostawcy/kanału/konfiguracji pojawiają się w onboardingu przed załadowaniem runtime. package.json#openclaw.install informuje onboarding, jak pobrać lub włączyć ten Plugin, gdy użytkownik wybierze jedną z tych opcji. Nie przenoś wskazówek instalacji do openclaw.plugin.json.

openclaw.install.minHostVersion jest egzekwowane podczas instalacji i ładowania rejestru manifestów dla niedołączonych źródeł Plugin. Nieprawidłowe wartości są odrzucane; nowsze, ale prawidłowe wartości pomijają zewnętrzne Plugin na starszych hostach. Dołączone źródłowe Plugin są uznawane za współwersjonowane z checkoutem hosta.

openclaw.install.requiredPlatformPackages służy pakietom npm, które udostępniają wymagane natywne pliki binarne przez opcjonalne, specyficzne dla platformy aliasy. Wymień gołą nazwę pakietu npm dla każdego obsługiwanego aliasu platformowego. Podczas instalacji npm OpenClaw weryfikuje tylko zadeklarowany alias, którego ograniczenia lockfile pasują do bieżącego hosta. Jeśli npm zgłosi powodzenie, ale pominie ten alias, OpenClaw ponawia próbę raz ze świeżą pamięcią podręczną i wycofuje instalację, jeśli alias nadal jest brakujący.

openclaw.compat.pluginApi jest egzekwowane podczas instalacji pakietu dla niedołączonych źródeł Plugin. Używaj go dla minimalnej wersji API OpenClaw plugin SDK/runtime, względem której pakiet został zbudowany. Może być bardziej rygorystyczne niż minHostVersion, gdy pakiet Plugin potrzebuje nowszego API, ale nadal zachowuje niższą wskazówkę instalacji dla innych przepływów. Oficjalna synchronizacja wydań OpenClaw domyślnie podnosi istniejące oficjalne minimalne wersje API Plugin do wersji wydania OpenClaw, ale wydania dotyczące tylko Plugin mogą zachować niższą minimalną wersję, gdy pakiet celowo obsługuje starsze hosty. Nie używaj samej wersji pakietu jako kontraktu zgodności. peerDependencies.openclaw pozostaje metadanymi pakietu npm; OpenClaw używa kontraktu openclaw.compat.pluginApi do decyzji o zgodności instalacji.

Oficjalne metadane instalacji na żądanie powinny używać clawhubSpec, gdy Plugin jest opublikowany w ClawHub; onboarding traktuje to jako preferowane zdalne źródło i zapisuje fakty artefaktu ClawHub po instalacji. npmSpec pozostaje rezerwową ścieżką zgodności dla pakietów, które jeszcze nie zostały przeniesione do ClawHub.

Dokładne przypinanie wersji npm już znajduje się w npmSpec, na przykład "npmSpec": "@wecom/wecom-openclaw-plugin@1.2.3". Oficjalne zewnętrzne wpisy katalogu powinny łączyć dokładne specyfikacje z expectedIntegrity, aby przepływy aktualizacji kończyły się bezpieczną odmową, jeśli pobrany artefakt npm nie pasuje już do przypiętego wydania. Interaktywny onboarding nadal oferuje zaufane specyfikacje npm z rejestru, w tym gołe nazwy pakietów i dist-tags, dla zgodności. Diagnostyka katalogu może rozróżniać źródła dokładne, pływające, przypięte integralnością, bez integralności, z niezgodną nazwą pakietu i z nieprawidłowym domyślnym wyborem. Ostrzega także, gdy expectedIntegrity jest obecne, ale nie ma prawidłowego źródła npm, które może przypiąć. Gdy expectedIntegrity jest obecne, przepływy instalacji/aktualizacji je egzekwują; gdy jest pominięte, rozwiązanie rejestru jest zapisywane bez przypięcia integralności.

Pluginy kanałów powinny dostarczać openclaw.setupEntry, gdy skany statusu, listy kanałów lub SecretRef muszą identyfikować skonfigurowane konta bez ładowania pełnego runtime. Punkt wejścia konfiguracji powinien udostępniać metadane kanału oraz bezpieczne dla konfiguracji adaptery konfiguracji, statusu i sekretów; klientów sieciowych, listenery Gateway i runtime transportu trzymaj w głównym punkcie wejścia rozszerzenia.

Pola punktów wejścia runtime nie nadpisują kontroli granic pakietu dla źródłowych pól punktów wejścia. Na przykład openclaw.runtimeExtensions nie może sprawić, że wychodząca poza granice ścieżka openclaw.extensions stanie się możliwa do załadowania.

openclaw.install.allowInvalidConfigRecovery jest celowo wąskie. Nie sprawia, że dowolne uszkodzone konfiguracje stają się instalowalne. Obecnie pozwala przepływom instalacji odzyskać działanie tylko po konkretnych przestarzałych awariach aktualizacji dołączonego Plugin, takich jak brakująca ścieżka dołączonego Plugin lub przestarzały wpis channels.<id> dla tego samego dołączonego Plugin. Niepowiązane błędy konfiguracji nadal blokują instalację i kierują operatorów do openclaw doctor --fix.

openclaw.channel.persistedAuthState to metadane pakietu dla małego modułu sprawdzającego:

{  "openclaw": {    "channel": {      "id": "whatsapp",      "persistedAuthState": {        "specifier": "./auth-presence",        "exportName": "hasAnyWhatsAppAuth"      }    }  }}

Używaj go, gdy przepływy konfiguracji, doctor, statusu lub obecności w trybie tylko do odczytu potrzebują taniej sondy uwierzytelnienia tak/nie przed załadowaniem pełnego Plugin kanału. Utrwalony stan uwierzytelnienia nie jest skonfigurowanym stanem kanału: nie używaj tych metadanych do automatycznego włączania Plugin, naprawiania zależności runtime ani decydowania, czy runtime kanału powinien się załadować. Docelowy eksport powinien być małą funkcją, która odczytuje tylko utrwalony stan; nie kieruj go przez pełny barrel runtime kanału.

openclaw.channel.configuredState ma ten sam kształt dla tanich sprawdzeń konfiguracji opartych tylko na env:

{  "openclaw": {    "channel": {      "id": "telegram",      "configuredState": {        "specifier": "./configured-state",        "exportName": "hasTelegramConfiguredState"      }    }  }}

Używaj go, gdy kanał może odpowiedzieć o stanie konfiguracji na podstawie env lub innych małych wejść spoza runtime. Jeśli sprawdzenie wymaga pełnego rozwiązywania konfiguracji albo rzeczywistego runtime kanału, zostaw tę logikę w hooku Plugin config.hasConfiguredState.

Pierwszeństwo odkrywania (zduplikowane identyfikatory Plugin)

OpenClaw odkrywa Plugin z kilku katalogów głównych. Surową kolejność skanowania systemu plików znajdziesz w Kolejność skanowania Plugin . Jeśli dwa odkrycia mają ten sam id, zachowywany jest tylko manifest o najwyższym pierwszeństwie; duplikaty o niższym pierwszeństwie są odrzucane zamiast ładowania obok niego.

Pierwszeństwo, od najwyższego do najniższego:

1. Wybrane w konfiguracji — ścieżka jawnie przypięta w plugins.entries.<id>
2. Dołączone — Plugin dostarczane z OpenClaw
3. Instalacja globalna — Plugin zainstalowane w globalnym katalogu głównym Plugin OpenClaw
4. Workspace — Plugin odkryte względem bieżącego workspace

Konsekwencje:

• Sforkowana lub przestarzała kopia dołączonego Plugin znajdująca się w workspace nie przesłoni dołączonego buildu.
• Aby faktycznie zastąpić dołączony Plugin lokalnym, przypnij go przez plugins.entries.<id>, aby wygrał przez pierwszeństwo, zamiast polegać na odkrywaniu workspace.
• Odrzucenia duplikatów są logowane, aby Doctor i diagnostyka uruchamiania mogły wskazać odrzuconą kopię.
• Nadpisania duplikatów wybranych w konfiguracji są w diagnostyce formułowane jako jawne nadpisania, ale nadal ostrzegają, aby przestarzałe forki i przypadkowe przesłonięcia pozostały widoczne.

Wymagania JSON Schema

• Każdy plugin musi dostarczać JSON Schema, nawet jeśli nie przyjmuje żadnej konfiguracji.
• Pusty schemat jest dopuszczalny (na przykład { "type": "object", "additionalProperties": false }).
• Schematy są weryfikowane podczas odczytu/zapisu konfiguracji, a nie w czasie wykonywania.
• Podczas rozszerzania lub forkowania dołączonego pluginu o nowe klucze konfiguracji zaktualizuj jednocześnie configSchema w openclaw.plugin.json tego pluginu. Schematy dołączonych pluginów są rygorystyczne, więc dodanie plugins.entries.<id>.config.myNewKey w konfiguracji użytkownika bez dodania myNewKey do configSchema.properties zostanie odrzucone przed załadowaniem środowiska wykonawczego pluginu.

Przykładowe rozszerzenie schematu:

{  "configSchema": {    "type": "object",    "additionalProperties": false,    "properties": {      "myNewKey": {        "type": "string"      }    }  }}

Zachowanie walidacji

• Nieznane klucze channels.* są błędami, chyba że identyfikator kanału jest zadeklarowany przez manifest pluginu.
• plugins.entries.<id>, plugins.allow, plugins.deny i plugins.slots.* muszą odwoływać się do wykrywalnych identyfikatorów pluginów. Nieznane identyfikatory są błędami.
• Jeśli plugin jest zainstalowany, ale ma uszkodzony albo brakujący manifest lub schemat, walidacja kończy się niepowodzeniem, a Doctor zgłasza błąd pluginu.
• Jeśli konfiguracja pluginu istnieje, ale plugin jest wyłączony, konfiguracja zostaje zachowana, a ostrzeżenie jest pokazywane w Doctorze i logach.

Zobacz Informacje o konfiguracji, aby poznać pełny schemat plugins.*.

Uwagi

• Manifest jest wymagany dla natywnych pluginów OpenClaw, w tym ładowanych z lokalnego systemu plików. Runtime nadal ładuje moduł pluginu osobno; manifest służy tylko do wykrywania i walidacji.
• Natywne manifesty są parsowane za pomocą JSON5, więc komentarze, końcowe przecinki i nieujęte w cudzysłów klucze są akceptowane, o ile końcowa wartość nadal jest obiektem.
• Loader manifestów odczytuje tylko udokumentowane pola manifestu. Unikaj niestandardowych kluczy najwyższego poziomu.
• channels, providers, cliBackends i skills można pominąć, gdy plugin ich nie potrzebuje.
• providerCatalogEntry musi pozostać lekki i nie powinien importować rozbudowanego kodu runtime; używaj go do statycznych metadanych katalogu dostawców lub wąskich deskryptorów wykrywania, a nie do wykonywania w czasie obsługi żądania.
• Wyłączne rodzaje pluginów wybiera się przez plugins.slots.*: kind: "memory" przez plugins.slots.memory, kind: "context-engine" przez plugins.slots.contextEngine (domyślnie legacy).
• Zadeklaruj wyłączny rodzaj pluginu w tym manifeście. OpenClawPluginDefinition.kind w punkcie wejścia runtime jest przestarzałe i pozostaje tylko jako fallback zgodności dla starszych pluginów.
• Metadane zmiennych środowiskowych (setup.providers[].envVars, przestarzałe providerAuthEnvVars oraz channelEnvVars) mają wyłącznie charakter deklaratywny. Status, audyt, walidacja dostarczania przez cron i inne powierzchnie tylko do odczytu nadal stosują zaufanie do pluginu oraz efektywną politykę aktywacji, zanim potraktują zmienną środowiskową jako skonfigurowaną.
• Metadane kreatora runtime wymagające kodu dostawcy opisano w hookach runtime dostawcy.
• Jeśli Twój plugin zależy od modułów natywnych, udokumentuj kroki kompilacji oraz wszelkie wymagania dotyczące listy dozwolonych pakietów menedżera pakietów (na przykład pnpm allow-build-scripts + pnpm rebuild <package>).

Powiązane