Manifesto do Plugin

Esta página aborda o manifesto nativo de Plugin do OpenClaw, openclaw.plugin.json. Para layouts de pacotes compatíveis (Codex, Claude, Cursor), consulte Pacotes de Plugins.

Os formatos de pacote compatíveis usam seus próprios arquivos de manifesto:

• Pacote do Codex: .codex-plugin/plugin.json
• Pacote do Claude: .claude-plugin/plugin.json ou o layout padrão de componentes do Claude sem manifesto
• Pacote do Cursor: .cursor-plugin/plugin.json

O OpenClaw detecta esses layouts automaticamente, mas não os valida de acordo com o esquema de openclaw.plugin.json abaixo. Para um pacote compatível, o OpenClaw lê os metadados do pacote, as raízes de Skills declaradas, as raízes de comandos do Claude, os padrões de settings.json do Claude, os padrões de LSP do Claude e os pacotes de hooks compatíveis, quando o layout corresponde às expectativas de runtime do OpenClaw.

Todo Plugin nativo do OpenClaw deve incluir openclaw.plugin.json na raiz do Plugin. O OpenClaw o lê para validar a configuração sem executar o código do Plugin. Um manifesto ausente ou inválido impede a validação da configuração e é tratado como um erro do Plugin.

Consulte Plugins para ver o guia completo do sistema de Plugins e Modelo de capacidades para conhecer o modelo nativo de capacidades e as orientações atuais de compatibilidade externa.

O que este arquivo faz

openclaw.plugin.json contém metadados que o OpenClaw lê antes de carregar o código do seu Plugin. Tudo nele deve ser leve o suficiente para ser inspecionado sem iniciar o runtime do Plugin.

Use-o para:

• identidade do Plugin, validação da configuração e dicas para a interface de configuração
• metadados de autenticação, integração inicial e configuração (alias, ativação automática, variáveis de ambiente do provedor, opções de autenticação)
• dicas de ativação para superfícies do plano de controle
• atribuição abreviada de famílias de modelos
• instantâneos estáticos de atribuição de capacidades (contracts)
• metadados do executor de controle de qualidade que o host compartilhado openclaw qa pode inspecionar
• metadados de configuração específicos do canal, mesclados às superfícies de catálogo e validação

Não o use para: registrar comportamentos de runtime, declarar pontos de entrada de código ou metadados de instalação do npm. Esses elementos pertencem ao código do seu Plugin e ao package.json.

Exemplo mínimo

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

Exemplo completo

{  "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"      }    }  }}

Referência dos campos de nível superior

referência de catalog

catalog fornece dicas opcionais de exibição para navegadores de Plugins. Os hosts podem ignorar essas dicas. Elas nunca instalam nem habilitam o Plugin e não alteram seu comportamento em tempo de execução nem seu nível de confiança.

{  "catalog": {    "featured": true,    "order": 10  }}

Referência de metadados de provedores de geração

Os campos de metadados de provedores de geração descrevem sinais estáticos de autenticação para os provedores declarados na lista contracts.*GenerationProviders correspondente. O OpenClaw lê esses campos antes do carregamento do tempo de execução do provedor, permitindo que as ferramentas centrais determinem se um provedor de geração está disponível sem importar todos os Plugins de provedor.

Use esses campos apenas para fatos declarativos de baixo custo. Transporte, transformações de solicitações, renovação de tokens, validação de credenciais e o comportamento efetivo de geração permanecem no tempo de execução do Plugin.

{  "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"]          }        }      ]    }  }}

Cada entrada de metadados oferece suporte a:

Cada entrada de configSignals oferece suporte a:

Cada restrição mode oferece suporte a:

Cada entrada de authSignals oferece suporte a:

Cada restrição providerBaseUrl oferece suporte a:

Referência de metadados de ferramentas

toolMetadata usa os mesmos formatos de configSignals e authSignals que os metadados de provedores de geração, indexados pelo nome da ferramenta. contracts.tools declara a propriedade. toolMetadata declara evidências de disponibilidade de baixo custo para que o OpenClaw possa evitar importar o tempo de execução de um Plugin apenas para que sua fábrica de ferramentas retorne 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"]        }      ]    }  }}

As entradas de toolMetadata também aceitam optional (marca a ferramenta como não obrigatória para a ativação do Plugin) e replaySafe (marca a execução da ferramenta como segura para repetição após um turno incompleto do modelo), além dos campos compartilhados de configSignals/authSignals acima.

Se uma ferramenta não tiver toolMetadata, o OpenClaw preservará o comportamento existente e carregará o Plugin proprietário quando o contrato da ferramenta corresponder à política. Para ferramentas em caminhos críticos cuja fábrica depende de autenticação/configuração, os autores de Plugins devem declarar toolMetadata em vez de fazer o núcleo importar o tempo de execução para consultá-lo.

Referência de providerAuthChoices

Cada entrada de providerAuthChoices descreve uma opção de integração inicial ou autenticação. O OpenClaw lê essa informação antes do carregamento do tempo de execução do provedor. As listas de configuração de provedores usam essas opções do manifesto, opções de configuração derivadas de descritores e metadados do catálogo de instalação sem carregar o tempo de execução do provedor.

Referência de commandAliases

Use commandAliases quando um plugin for responsável por um nome de comando de runtime que os usuários possam inserir por engano em plugins.allow ou tentar executar como um comando raiz da CLI. O OpenClaw usa esses metadados para diagnósticos sem importar o código de runtime do plugin.

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

Referência de activation

Use activation quando o plugin puder declarar de forma econômica quais eventos do plano de controle devem incluí-lo em um plano de ativação/carregamento.

Este bloco contém metadados do planejador, não uma API de ciclo de vida. Ele não registra comportamentos de runtime, não substitui register(...) e não garante que o código do plugin já tenha sido executado. O planejador de ativação usa esses campos para restringir os plugins candidatos antes de recorrer aos metadados de propriedade existentes no manifesto, como providers, channels, commandAliases, setup.providers, contracts.tools e hooks.

Prefira os metadados mais específicos que já descrevam a propriedade. Use providers, channels, commandAliases, descritores de configuração ou contracts quando esses campos expressarem a relação. Use activation para dicas adicionais ao planejador que não possam ser representadas por esses campos de propriedade. Use cliBackends no nível superior para aliases de runtime da CLI, como claude-cli, my-cli ou google-gemini-cli; activation.onAgentHarnesses destina-se somente a IDs de harnesses de agente incorporados que ainda não tenham um campo de propriedade.

Todo plugin deve definir activation.onStartup intencionalmente. Defina-o como true somente quando o plugin precisar ser executado durante a inicialização do Gateway. Defina-o como false quando o plugin estiver inerte na inicialização e só deva ser carregado por gatilhos mais específicos. Omitir onStartup não faz mais com que o plugin seja carregado implicitamente na inicialização; use metadados de ativação explícitos para gatilhos de inicialização, canal, configuração, harness de agente, memória ou outros gatilhos mais específicos.

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

Consumidores ativos atuais:

• O planejamento da inicialização do Gateway usa activation.onStartup para a importação explícita na inicialização.
• O planejamento da CLI acionado por comandos recorre ao legado commandAliases[].cliCommand ou commandAliases[].name.
• O planejamento da inicialização do runtime do agente usa activation.onAgentHarnesses para harnesses incorporados e cliBackends[] no nível superior para aliases de runtime da CLI.
• O planejamento de configuração/canal acionado por canal recorre à propriedade legada channels[] quando faltam metadados explícitos de ativação de canal.
• O planejamento de plugins na inicialização usa activation.onConfigPaths para áreas de configuração raiz que não sejam de canal, como o bloco browser do plugin de navegador incluído.
• O planejamento de configuração/runtime acionado por provedor recorre à propriedade legada providers[] e cliBackends[] no nível superior quando faltam metadados explícitos de ativação de provedor.

Os diagnósticos do planejador podem distinguir dicas explícitas de ativação do uso alternativo da propriedade do manifesto. Por exemplo, activation-command-hint significa que activation.onCommands correspondeu, enquanto manifest-command-alias significa que o planejador usou a propriedade de commandAliases. Esses rótulos de motivo destinam-se a diagnósticos e testes do host; os autores de plugins devem continuar declarando os metadados que melhor descrevem a propriedade.

Referência de qaRunners

Use qaRunners quando um plugin fornecer um ou mais executores de transporte sob a raiz compartilhada openclaw qa. Mantenha esses metadados leves e estáticos; o runtime do plugin continua responsável pelo registro efetivo da CLI por meio de uma interface leve runtime-api.ts que exporta qaRunnerCliRegistrations correspondentes. Um adapterFactory opcional expõe o transporte a cenários compartilhados de QA sem alterar o executor do comando registrado.

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

O id de adapterFactory deve corresponder a commandName. Não exporte registros para comandos ausentes do manifesto.

Referência de setup

Use setup quando as interfaces de configuração e integração inicial precisarem de metadados econômicos pertencentes ao plugin antes do carregamento do runtime.

{  "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  }}

O cliBackends de nível superior continua válido e descrevendo backends de inferência da CLI. setup.cliBackends é a interface de descritores específica de configuração para fluxos do plano de controle e de configuração que devem permanecer baseados apenas em metadados.

Quando presentes, setup.providers e setup.cliBackends são a interface preferencial de consulta que prioriza descritores para a descoberta de configuração. Se o descritor apenas restringir o plugin candidato e a configuração ainda precisar de hooks de runtime mais completos durante a configuração, defina requiresRuntime: true e mantenha setup-api como caminho de execução alternativo.

O OpenClaw também inclui setup.providers[].envVars nas consultas genéricas de autenticação de provedores e de variáveis de ambiente. providerAuthEnvVars continua compatível por meio de um adaptador durante o período de descontinuação, mas plugins não integrados que ainda o utilizam recebem um diagnóstico de manifesto. Novos plugins devem colocar metadados de ambiente de configuração/status em setup.providers[].envVars.

Use providerUsageAuthEnvVars quando uma credencial de faturamento ou de nível organizacional precisar ativar resolveUsageAuth sem se tornar uma credencial de inferência. Esses nomes são adicionados ao bloqueio do dotenv do espaço de trabalho, à remoção em processos filhos ACP, à filtragem de segredos do sandbox e à limpeza ampla de segredos. O runtime do provedor ainda lê e classifica o valor dentro de resolveUsageAuth.

O OpenClaw também pode derivar opções simples de configuração de setup.providers[].authMethods quando nenhuma entrada de configuração estiver disponível ou quando setup.requiresRuntime: false declarar que o runtime de configuração é desnecessário. As entradas explícitas de providerAuthChoices continuam sendo preferidas para rótulos personalizados, flags da CLI, escopo de integração inicial e metadados do assistente.

Defina requiresRuntime: false somente quando esses descritores forem suficientes para a interface de configuração. O OpenClaw trata o valor false explícito como um contrato baseado apenas em descritores e não executará setup-api nem openclaw.setupEntry para a consulta de configuração. Se um plugin baseado apenas em descritores ainda incluir uma dessas entradas de runtime de configuração, o OpenClaw emitirá um diagnóstico adicional e continuará ignorando-a. A omissão de requiresRuntime mantém o comportamento legado de fallback para não interromper plugins existentes que adicionaram descritores sem a flag.

Como a consulta de configuração pode executar código setup-api pertencente ao plugin, os valores normalizados de setup.providers[].id e setup.cliBackends[] devem permanecer únicos entre os plugins descobertos. Em caso de propriedade ambígua, o processo falha de forma segura em vez de escolher um vencedor com base na ordem de descoberta.

Quando o runtime de configuração é executado, os diagnósticos do registro de configuração informam divergências de descritores caso setup-api registre um provedor ou backend da CLI que os descritores do manifesto não declarem, ou caso um descritor não tenha um registro correspondente no runtime. Esses diagnósticos são adicionais e não rejeitam plugins legados.

Referência de setup.providers

authEvidence destina-se a marcadores locais de credenciais pertencentes ao provedor que podem ser verificados sem carregar código de runtime. Essas verificações devem permanecer econômicas e locais: sem chamadas de rede, leituras de chaveiros ou gerenciadores de segredos, comandos do shell nem sondagens da API do provedor.

Entradas de evidência compatíveis:

Campos de setup

Referência de uiHints

uiHints é um mapa dos nomes dos campos de configuração para pequenas dicas de renderização. As chaves podem usar pontos para campos de configuração aninhados, mas nenhum segmento do caminho pode ser __proto__, constructor ou prototype; a configuração rejeita esses nomes.

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

Cada dica de campo pode incluir:

Referência de contracts

Use contracts somente para metadados estáticos de propriedade de recursos que o OpenClaw possa ler sem importar o runtime do plugin.

{  "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"],    "musicGenerationProviders": ["stability-audio"],    "documentExtractors": ["example-docs"],    "webContentExtractors": ["firecrawl"],    "webFetchProviders": ["firecrawl"],    "webSearchProviders": ["gemini"],    "workerProviders": ["example-worker"],    "usageProviders": ["acme-ai"],    "migrationProviders": ["hermes"],    "gatewayMethodDispatch": ["authenticated-request"],    "tools": ["firecrawl_search", "firecrawl_scrape"]  }}

Cada lista é opcional:

contracts.embeddedExtensionFactories é mantido para fábricas integradas de extensões exclusivas do servidor de aplicativos do Codex. As transformações integradas de resultados de ferramentas devem declarar contracts.agentToolResultMiddleware e, em vez disso, registrar-se com api.registerAgentToolResultMiddleware(...). Plugins instalados podem usar o mesmo ponto de integração de middleware somente quando explicitamente habilitados e apenas para os runtimes que declaram em contracts.agentToolResultMiddleware.

Plugins instalados que precisam da camada de políticas pré-ferramenta confiáveis pelo host devem declarar cada ID local registrado em contracts.trustedToolPolicies e ser explicitamente habilitados. Plugins integrados mantêm o caminho existente de políticas confiáveis, mas Plugins instalados com IDs de política não declarados são rejeitados antes do registro. Os IDs de política têm escopo restrito ao Plugin que os registra; portanto, dois Plugins podem declarar e registrar workflow-budget, mas um único Plugin não pode registrar duas vezes o mesmo ID local.

Os registros de api.registerTool(...) no runtime devem corresponder a contracts.tools. A descoberta de ferramentas usa essa lista para carregar apenas os runtimes de Plugins que podem ser responsáveis pelas ferramentas solicitadas.

Plugins de provedores que implementam resolveExternalAuthProfiles devem declarar contracts.externalAuthProviders; hooks de autenticação externa não declarados são ignorados.

Plugins de provedores que implementam tanto resolveUsageAuth quanto fetchUsageSnapshot devem declarar cada ID de provedor descoberto automaticamente em contracts.usageProviders. A descoberta de uso lê esse contrato antes de carregar o código de runtime e, depois, verifica ambos os hooks após carregar apenas os responsáveis declarados.

Provedores gerais de embeddings devem declarar contracts.embeddingProviders para cada adaptador registrado com api.registerEmbeddingProvider(...). Use o contrato geral para a geração reutilizável de vetores, incluindo provedores consumidos pela pesquisa de memória. contracts.memoryEmbeddingProviders é uma compatibilidade obsoleta específica de memória e permanece apenas enquanto os provedores existentes migram para o ponto de integração genérico de provedores de embeddings.

Provedores de workers devem declarar cada ID de api.registerWorkerProvider(...) em contracts.workerProviders. O núcleo persiste a intenção durável antes de chamar provision; os provedores validam suas configurações antes da alocação externa, e chamadas repetidas com o mesmo ID de operação devem adotar a mesma concessão. O núcleo também persiste esse instantâneo das configurações validadas e o passa com leaseId para inspect({ leaseId, profile }) e destroy({ leaseId, profile }), inclusive depois que o perfil nomeado é alterado ou removido. A destruição é idempotente, a inspeção retorna a união fechada de status active / destroyed / unknown, e o material de chave privada SSH é referenciado somente por meio de SecretRef. Endpoints SSH provisionados também devem incluir uma hostKey pública proveniente de uma saída de provisionamento confiável, exatamente no formato algorithm base64, sem nome de host nem comentário, para que o núcleo possa fixar a chave do host antes de se conectar. Provedores que criam referências dinâmicas de identidade podem implementar o método autoritativo resolveSshIdentity({ leaseId, profile, keyRef }); provedores sem ele usam o resolvedor genérico de segredos do núcleo. Um resultado autoritativo unknown torna órfão um registro local ativo; após uma solicitação de destruição persistida, ele confirma o encerramento.

Atualmente, contracts.gatewayMethodDispatch aceita "authenticated-request". Trata-se de uma barreira de higiene da API para rotas HTTP nativas de Plugins que despacham intencionalmente métodos do plano de controle do Gateway no processo, e não de uma sandbox contra Plugins nativos mal-intencionados. Use-o somente para superfícies integradas ou de operador rigorosamente revisadas que já exigem autenticação HTTP do Gateway. Uma rota com essa permissão permanece acessível enquanto a admissão de trabalhos raiz do Gateway está fechada somente quando também declara auth: "gateway" e o gatewayRuntimeScopeSurface: "trusted-operator" específico da rota; as rotas irmãs comuns do mesmo Plugin permanecem atrás do limite de admissão. Isso mantém o status de suspensão e a retomada acessíveis sem conceder a todo o Plugin uma exceção à admissão. Mantenha a análise e a formatação da resposta limitadas fora do despacho; trabalhos substanciais ou que alterem estado devem passar pelo despacho de métodos do Gateway, responsável por impor a admissão e o escopo.

Referência de configContracts

Use configContracts para comportamentos de configuração pertencentes ao manifesto dos quais os auxiliares genéricos do núcleo precisam sem importar o runtime do Plugin: detecção de indicadores perigosos, destinos de migração de SecretRef e restrição de caminhos de configuração legados.

{  "configContracts": {    "compatibilityMigrationPaths": ["legacyProvider"],    "compatibilityRuntimePaths": ["legacyProvider.webhook"],    "dangerousFlags": [      {        "path": "accounts.*.allowUnverifiedSenders",        "equals": true      }    ],    "secretInputs": {      "bundledDefaultEnabled": false,      "paths": [        {          "path": "apiKey",          "expected": "string"        }      ]    }  }}

Cada entrada de dangerousFlags oferece suporte a:

secretInputs oferece suporte a:

Referência de mediaUnderstandingProviderMetadata

Use mediaUnderstandingProviderMetadata quando um provedor de compreensão de mídia tiver modelos padrão, prioridade de fallback de autenticação automática ou suporte nativo a documentos de que os auxiliares genéricos do núcleo precisem antes do carregamento do runtime. As chaves também devem ser declaradas em contracts.mediaUnderstandingProviders.

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

Cada entrada de provedor pode incluir:

Referência de channelConfigs

Use channelConfigs quando um plugin de canal precisar de metadados leves de configuração antes do carregamento do runtime. A descoberta somente leitura de configuração/status do canal pode usar esses metadados diretamente para canais externos configurados quando nenhuma entrada de configuração inicial estiver disponível ou quando setup.requiresRuntime: false declarar que o runtime de configuração inicial é desnecessário.

channelConfigs são metadados do manifesto do plugin, não uma nova seção de configuração de usuário de nível superior. Os usuários ainda configuram instâncias de canal em channels.<channel-id>. O OpenClaw lê os metadados do manifesto para decidir qual plugin é responsável por esse canal configurado antes da execução do código de runtime do plugin.

Para um plugin de canal, configSchema e channelConfigs descrevem caminhos diferentes:

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

Plugins não incluídos que declaram channels[] também devem declarar entradas channelConfigs correspondentes. Sem elas, o OpenClaw ainda pode carregar o plugin, mas as superfícies de esquema de configuração do caminho frio, configuração inicial e Control UI não podem conhecer o formato das opções pertencentes ao canal até que o runtime do plugin seja executado.

channelConfigs.<channel-id>.commands.nativeCommandsAutoEnabled e nativeSkillsAutoEnabled podem declarar padrões estáticos de auto para verificações da configuração de comandos executadas antes do carregamento do runtime do canal. Canais incluídos também podem publicar os mesmos padrões por meio de package.json#openclaw.channel.commands, juntamente com seus outros metadados do catálogo de canais pertencentes ao pacote.

{  "channelConfigs": {    "matrix": {      "schema": {        "type": "object",        "additionalProperties": false,        "properties": {          "homeserverUrl": { "type": "string" }        }      },      "uiHints": {        "homeserverUrl": {          "label": "URL do servidor doméstico",          "placeholder": "https://matrix.example.com"        }      },      "label": "Matrix",      "description": "Conexão com o servidor doméstico Matrix",      "commands": {        "nativeCommandsAutoEnabled": true,        "nativeSkillsAutoEnabled": true      },      "preferOver": ["matrix-legacy"]    }  }}

Cada entrada de canal pode incluir:

Substituição de outro plugin de canal

Use preferOver quando seu plugin for o responsável preferencial por um ID de canal que outro plugin também possa fornecer. Casos comuns incluem um ID de plugin renomeado, um plugin independente que substitui um plugin incluído ou uma bifurcação mantida que preserva o mesmo ID de canal para compatibilidade de configuração.

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

Quando channels.chat está configurado, o OpenClaw considera tanto o ID do canal quanto o ID do plugin preferencial. Se o plugin de menor prioridade tiver sido selecionado apenas por estar incluído ou ativado por padrão, o OpenClaw o desativará na configuração efetiva do runtime, de modo que um único plugin seja responsável pelo canal e por suas ferramentas. A seleção explícita do usuário ainda prevalece: se o usuário ativar explicitamente ambos os plugins (por meio de plugins.allow ou de uma configuração substancial em plugins.entries), o OpenClaw preservará essa escolha e relatará diagnósticos de canais/ferramentas duplicados, em vez de alterar silenciosamente o conjunto de plugins solicitado.

Mantenha preferOver restrito a IDs de plugins que realmente possam fornecer o mesmo canal. Ele não é um campo geral de prioridade e não renomeia chaves de configuração do usuário.

Referência de modelSupport

Use modelSupport quando o OpenClaw precisar inferir seu plugin de provedor a partir de IDs abreviados de modelos, como gpt-5.6-sol ou claude-sonnet-4.6, antes do carregamento do runtime do plugin.

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

O OpenClaw aplica esta precedência:

• referências explícitas provider/model usam os metadados do manifesto providers do responsável
• modelPatterns prevalecem sobre modelPrefixes
• se um plugin não incluído e um plugin incluído corresponderem, o plugin não incluído prevalecerá
• qualquer ambiguidade restante será ignorada até que o usuário ou a configuração especifique um provedor

Campos:

As entradas de modelPatterns são compiladas por meio de compileSafeRegex, que rejeita padrões contendo repetição aninhada (por exemplo, (a+)+$). Padrões que não passam na verificação de segurança são ignorados silenciosamente, assim como expressões regulares sintaticamente inválidas. Mantenha os padrões simples e evite quantificadores aninhados.

Referência de modelCatalog

Use modelCatalog quando o OpenClaw precisar conhecer os metadados dos modelos do provedor antes de carregar o runtime do plugin. Esta é a fonte pertencente ao manifesto para linhas fixas do catálogo, aliases de provedores, regras de supressão e modo de descoberta. A atualização do runtime continua pertencendo ao código de runtime do provedor, mas o manifesto informa ao núcleo quando o runtime é necessário.

{  "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"    }  }}

Campos de nível superior:

aliases participa da consulta de propriedade do provedor para o planejamento do catálogo de modelos. Os destinos dos aliases devem ser provedores de nível superior pertencentes ao mesmo plugin. Quando uma lista filtrada por provedor usa um alias, o OpenClaw pode ler o manifesto proprietário e aplicar substituições de API/URL base do alias sem carregar o ambiente de execução do provedor. Os aliases não expandem listagens de catálogo sem filtro; listas abrangentes emitem somente as linhas do provedor canônico proprietário.

suppressions substitui o antigo gancho suppressBuiltInModel do ambiente de execução do provedor. As entradas de supressão são respeitadas somente quando o provedor pertence ao plugin ou é declarado como uma chave de modelCatalog.aliases que aponta para um provedor pertencente ao plugin. Os ganchos de supressão do ambiente de execução não são mais chamados durante a resolução de modelos.

Campos do provedor:

Campos do modelo:

Campos de supressão:

Não coloque dados disponíveis somente em tempo de execução em modelCatalog. Use static somente quando as linhas do manifesto forem completas o suficiente para que listas filtradas por provedor e interfaces de seleção possam ignorar a descoberta por registro/ambiente de execução. Use refreshable quando as linhas do manifesto forem sementes ou complementos úteis para listagem, mas uma atualização/cache puder adicionar mais linhas posteriormente; linhas atualizáveis não são autoritativas por si só. Use runtime quando o OpenClaw precisar carregar o ambiente de execução do provedor para conhecer a lista.

Referência de modelIdNormalization

Use modelIdNormalization para a normalização simples de IDs de modelos pertencentes ao provedor que deve ocorrer antes do carregamento do ambiente de execução do provedor. Isso mantém aliases, como nomes curtos de modelos, IDs locais legados do provedor e regras de prefixos de proxy, no manifesto do plugin proprietário, em vez de nas tabelas principais de seleção de modelos.

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

Campos do provedor:

Referência de providerEndpoints

Use providerEndpoints para a classificação de endpoints que a política genérica de solicitações deve conhecer antes do carregamento do ambiente de execução do provedor. O núcleo continua responsável pelo significado de cada endpointClass; os manifestos dos plugins são responsáveis pelos metadados de host e URL base.

Plugins de provedores oficialmente externalizados são excluídos da distribuição principal, portanto, seus manifestos permanecem invisíveis até serem instalados. Seus providerEndpoints também devem ser espelhados em scripts/lib/official-external-provider-catalog.json para que a classificação de endpoints continue funcionando sem o plugin; um teste de contrato garante o espelhamento.

Campos do endpoint:

Referência de providerRequest

Use providerRequest para metadados leves de compatibilidade de solicitações necessários à política genérica de solicitações sem carregar o runtime do provedor. Mantenha a reescrita de payload específica de comportamento nos hooks de runtime do provedor ou em auxiliares compartilhados da família de provedores.

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

Campos do provedor:

Referência de secretProviderIntegrations

Use secretProviderIntegrations quando um plugin puder publicar uma predefinição reutilizável de provedor exec do SecretRef. O OpenClaw lê esses metadados antes de carregar o runtime do plugin, armazena a propriedade do plugin em secrets.providers.<alias>.pluginIntegration e deixa a resolução efetiva do segredo para o runtime do SecretRef. As predefinições são expostas somente para plugins incluídos no pacote e plugins instalados descobertos nas raízes gerenciadas de instalação de plugins, como instalações via git e ClawHub.

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

A chave do mapa é o ID da integração. Se providerAlias for omitido, o OpenClaw usará o ID da integração como alias do provedor SecretRef. Os aliases de provedor devem corresponder ao padrão normal de alias de provedor SecretRef, por exemplo, team-secrets ou onepassword-work.

Quando um operador seleciona a predefinição, o OpenClaw grava uma referência de provedor como:

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

Na inicialização ou recarga, o OpenClaw resolve esse provedor carregando os metadados atuais do manifesto do plugin, verificando se o plugin proprietário está instalado e ativo e materializando o comando exec a partir do manifesto. Desabilitar ou remover o plugin revoga o provedor para SecretRefs ativos. Operadores que desejam uma configuração exec autônoma ainda podem definir provedores manuais com command/args diretamente.

Atualmente, somente predefinições com source: "exec" são compatíveis. command deve ser ${node}, e args[0] deve ser um script resolvedor relativo à raiz do plugin iniciado por ./. Na inicialização ou recarga, o OpenClaw o materializa como o executável atual do Node e o caminho absoluto do script dentro do plugin. Opções do Node como --require, --import, --loader, --env-file, --eval e --print não fazem parte do contrato de predefinição do manifesto. Operadores que precisam de comandos que não sejam do Node podem configurar diretamente provedores exec manuais autônomos.

O OpenClaw deriva trustedDirs para predefinições do manifesto a partir da raiz do plugin e, para predefinições ${node}, do diretório do executável atual do Node. Valores trustedDirs definidos pelo manifesto são ignorados. Outras opções do provedor exec, como timeoutMs, noOutputTimeoutMs, maxOutputBytes, jsonOnly, env, passEnv e allowInsecurePath, são repassadas para a configuração normal do provedor exec do SecretRef.

Referência de modelPricing

Use modelPricing quando um provedor precisar controlar o comportamento de preços do plano de controle antes do carregamento do runtime. O cache de preços do Gateway lê esses metadados sem importar o código de runtime do provedor.

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

Campos do provedor:

Campos da fonte:

Índice de Provedores do OpenClaw

O Índice de Provedores do OpenClaw consiste em metadados de pré-visualização pertencentes ao OpenClaw para provedores cujos plugins talvez ainda não estejam instalados. Ele não faz parte do manifesto de um plugin. Os manifestos de plugins continuam sendo a autoridade para plugins instalados. O Índice de Provedores é o contrato interno de contingência que futuras interfaces de seleção de modelos e provedores instaláveis antes da instalação consumirão quando um plugin de provedor não estiver instalado.

Ordem de autoridade do catálogo:

1. Configuração do usuário.
2. modelCatalog do manifesto do plugin instalado.
3. Cache do catálogo de modelos proveniente de uma atualização explícita.
4. Linhas de pré-visualização do Índice de Provedores do OpenClaw.

O Índice de Provedores não deve conter segredos, estado de habilitação, hooks de runtime nem dados de modelos específicos de contas em tempo real. Seus catálogos de pré-visualização usam o mesmo formato de linha de provedor de modelCatalog que os manifestos de plugins, mas devem se limitar a metadados estáveis de exibição, a menos que campos do adaptador de runtime, como api, baseUrl, preços ou sinalizadores de compatibilidade, sejam intencionalmente mantidos alinhados ao manifesto do plugin instalado. Provedores com descoberta de /models em tempo real devem gravar linhas atualizadas pelo caminho explícito do cache do catálogo de modelos, em vez de fazer com que a listagem normal ou a integração inicial chame APIs de provedores.

As entradas do Índice de Provedores também podem incluir metadados de plugins instaláveis para provedores cujo plugin tenha sido movido para fora do núcleo ou ainda não esteja instalado por outro motivo. Esses metadados espelham o padrão do catálogo de canais: nome do pacote, especificação de instalação npm, integridade esperada e rótulos simples de opções de autenticação são suficientes para mostrar uma opção de configuração instalável. Depois que o plugin é instalado, seu manifesto prevalece, e a entrada do Índice de Provedores é ignorada para esse provedor.

openclaw doctor --fix migra um conjunto pequeno e fechado de chaves legadas de capacidade do manifesto no nível superior para contracts.*: speechProviders, mediaUnderstandingProviders, imageGenerationProviders e tools. Nenhuma delas, nem qualquer outra lista de capacidades, é mais lida como campo de manifesto no nível superior; o carregamento normal do manifesto só as reconhece em contracts.

Manifesto em comparação com package.json

Os dois arquivos têm funções diferentes:

Se você não tiver certeza de onde um metadado deve ficar, use esta regra:

• se o OpenClaw precisar conhecê-lo antes de carregar o código do plugin, coloque-o em openclaw.plugin.json
• se ele estiver relacionado ao empacotamento, arquivos de entrada ou comportamento de instalação do npm, coloque-o em package.json

Campos de package.json que afetam a descoberta

Alguns metadados de plugin anteriores ao runtime residem intencionalmente em package.json, no bloco openclaw, em vez de openclaw.plugin.json. openclaw.bundle e openclaw.bundle.json não são contratos de plugin do OpenClaw; plugins nativos devem usar openclaw.plugin.json junto aos campos compatíveis de package.json#openclaw abaixo.

Exemplos importantes:

Os metadados do manifesto determinam quais opções de provedor/canal/configuração aparecem na integração inicial antes do carregamento do runtime. package.json#openclaw.install informa à integração inicial como obter ou habilitar esse plugin quando o usuário escolhe uma dessas opções. Não mova as indicações de instalação para openclaw.plugin.json.

openclaw.install.minHostVersion é aplicado durante a instalação e o carregamento do registro de manifestos para fontes de plugins não incluídos. Valores inválidos são rejeitados; valores mais recentes, porém válidos, fazem com que plugins externos sejam ignorados em hosts mais antigos. Presume-se que plugins incluídos como código-fonte tenham a mesma versão do checkout do host.

openclaw.install.requiredPlatformPackages destina-se a pacotes npm que expõem binários nativos obrigatórios por meio de aliases opcionais e específicos de plataforma. Liste o nome simples do pacote npm para cada alias de plataforma compatível. Durante a instalação via npm, o OpenClaw verifica apenas o alias declarado cujas restrições no arquivo de lock correspondem ao host atual. Se o npm informar sucesso, mas omitir esse alias, o OpenClaw tenta novamente uma vez com um cache novo e reverte a instalação se o alias continuar ausente.

openclaw.compat.pluginApi é aplicado durante a instalação de pacotes para fontes de plugins não incluídos. Use-o para definir o limite inferior da API do SDK/runtime de plugins do OpenClaw para a qual o pacote foi compilado. Ele pode ser mais restritivo que minHostVersion quando um pacote de plugin precisa de uma API mais recente, mas ainda mantém uma indicação de instalação inferior para outros fluxos. Por padrão, a sincronização oficial de versões do OpenClaw eleva os limites inferiores existentes da API de plugins oficiais para a versão da distribuição do OpenClaw, mas distribuições exclusivas de plugins podem manter um limite inferior quando o pacote oferece compatibilidade intencional com hosts mais antigos. Não use apenas a versão do pacote como contrato de compatibilidade. peerDependencies.openclaw continua sendo metadado do pacote npm; o OpenClaw usa o contrato openclaw.compat.pluginApi para decisões de compatibilidade de instalação.

Os metadados oficiais de instalação sob demanda devem usar clawhubSpec quando o plugin for publicado no ClawHub; a integração inicial trata essa opção como a fonte remota preferencial e registra informações do artefato do ClawHub após a instalação. npmSpec continua sendo a alternativa de compatibilidade para pacotes que ainda não migraram para o ClawHub.

A fixação exata da versão npm já fica em npmSpec, por exemplo, "npmSpec": "@wecom/wecom-openclaw-plugin@1.2.3". As entradas oficiais do catálogo externo devem combinar especificações exatas com expectedIntegrity para que os fluxos de atualização falhem de forma segura se o artefato npm obtido deixar de corresponder à versão fixada. Para compatibilidade, a integração inicial interativa ainda oferece especificações npm de registros confiáveis, incluindo nomes simples de pacotes e dist-tags. Os diagnósticos do catálogo podem distinguir fontes exatas, flutuantes, fixadas por integridade, sem integridade, com incompatibilidade de nome de pacote e com opção padrão inválida. Eles também avisam quando expectedIntegrity está presente, mas não há uma fonte npm válida à qual possa ser vinculado. Quando expectedIntegrity está presente, os fluxos de instalação/atualização o aplicam; quando é omitido, a resolução do registro é registrada sem uma fixação de integridade.

Os plugins de canal devem fornecer openclaw.setupEntry quando as verificações de status, lista de canais ou SecretRef precisarem identificar contas configuradas sem carregar o runtime completo. O ponto de entrada de configuração deve expor os metadados do canal, além de adaptadores de configuração, status e segredos seguros para configuração; mantenha clientes de rede, listeners do Gateway e runtimes de transporte no ponto de entrada principal da extensão.

Os campos de ponto de entrada do runtime não substituem as verificações dos limites do pacote aplicadas aos campos de ponto de entrada do código-fonte. Por exemplo, openclaw.runtimeExtensions não pode tornar carregável um caminho de openclaw.extensions que saia do pacote.

openclaw.install.allowInvalidConfigRecovery é intencionalmente restrito. Ele não torna instaláveis configurações arbitrariamente corrompidas. Atualmente, ele apenas permite que os fluxos de instalação se recuperem de falhas específicas e obsoletas de atualização de plugins incluídos, como a ausência do caminho de um plugin incluído ou uma entrada channels.<id> obsoleta referente ao mesmo plugin incluído. Erros de configuração não relacionados ainda bloqueiam a instalação e encaminham os operadores para openclaw doctor --fix.

openclaw.channel.persistedAuthState é um metadado de pacote para um pequeno módulo verificador:

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

Use-o quando os fluxos de configuração, Doctor, status ou verificação de presença somente leitura precisarem de uma sondagem simples de autenticação com resposta sim/não antes do carregamento completo do plugin de canal. O estado de autenticação persistida não é o estado configurado do canal: não use esses metadados para habilitar plugins automaticamente, reparar dependências de runtime ou decidir se um runtime de canal deve ser carregado. A exportação de destino deve ser uma função pequena que leia apenas o estado persistido; não a encaminhe pelo barrel completo do runtime do canal.

openclaw.channel.configuredState segue a mesma estrutura para verificações simples do estado configurado somente por variáveis de ambiente:

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

Use-o quando um canal puder determinar o estado configurado a partir de variáveis de ambiente ou de outras entradas mínimas que não dependam do runtime. Se a verificação exigir a resolução completa da configuração ou o runtime real do canal, mantenha essa lógica no hook config.hasConfiguredState do plugin.

Precedência de descoberta (IDs de plugin duplicados)

O OpenClaw descobre plugins em três raízes, verificadas nesta ordem: plugins incluídos distribuídos com o OpenClaw, a raiz de instalação global (~/.openclaw/extensions) e a raiz do espaço de trabalho atual (<workspace>/.openclaw/extensions), além de quaisquer entradas explícitas em plugins.load.paths.

Se duas descobertas compartilharem o mesmo id, somente o manifesto de maior precedência será mantido; as duplicatas de menor precedência serão descartadas em vez de carregadas junto com ele. Precedência, da maior para a menor:

1. Selecionado pela configuração — um caminho fixado explicitamente em plugins.entries.<id>
2. Instalação global correspondente a um registro de instalação rastreado — um plugin instalado por meio de openclaw plugin install/openclaw plugin update que o rastreamento de instalações do OpenClaw reconheça para o mesmo ID, mesmo quando o ID também pertença a um plugin incluído
3. Incluído — plugins distribuídos com o OpenClaw
4. Espaço de trabalho — plugins descobertos em relação ao espaço de trabalho atual
5. Qualquer outro candidato descoberto

Implicações:

• Uma cópia derivada ou obsoleta de um plugin incluído, presente sem rastreamento no espaço de trabalho ou na raiz global, não substituirá a compilação incluída.
• Para substituir um plugin incluído, execute openclaw plugin install para esse ID, de modo que a instalação global rastreada tenha precedência sobre a cópia incluída, ou fixe um caminho específico por meio de plugins.entries.<id>, para que ele prevaleça pela precedência de seleção por configuração.
• Os descartes de duplicatas são registrados em log para que os diagnósticos do Doctor e da inicialização possam indicar a cópia descartada.
• As substituições de duplicatas selecionadas pela configuração são descritas como substituições explícitas nos diagnósticos, mas ainda geram avisos para que cópias derivadas obsoletas e sombreamentos acidentais permaneçam visíveis.

Requisitos do JSON Schema

• Todo plugin deve incluir um JSON Schema, mesmo que não aceite nenhuma configuração.
• Um schema vazio é aceitável (por exemplo, { "type": "object", "additionalProperties": false }).
• Os schemas são validados durante a leitura/gravação da configuração, não em tempo de execução.
• Ao estender ou criar um fork de um plugin incluído com novas chaves de configuração, atualize simultaneamente o configSchema do openclaw.plugin.json desse plugin. Os schemas dos plugins incluídos são estritos; portanto, adicionar plugins.entries.<id>.config.myNewKey à configuração do usuário sem adicionar myNewKey a configSchema.properties será rejeitado antes que o runtime do plugin seja carregado.

Exemplo de extensão de schema:

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

Comportamento da validação

• Chaves channels.* desconhecidas são erros, a menos que o ID do canal seja declarado pelo manifesto de um plugin. Se o mesmo ID também aparecer em plugins.allow, plugins.entries ou plugins.installs (um plugin referenciado, mas que não pode ser descoberto no momento), o OpenClaw rebaixa isso para um aviso.
• Referências a IDs de plugins desconhecidos em plugins.entries.<id>, plugins.allow e plugins.deny são avisos ("entrada de configuração obsoleta ignorada"), não erros, para que atualizações e plugins removidos/renomeados não impeçam a inicialização do Gateway.
• A referência de plugins.slots.memory a um ID de plugin desconhecido é um erro, exceto para o plugin externo oficial conhecido memory-lancedb, que gera um aviso.
• Se um plugin estiver instalado, mas tiver um manifesto ou schema ausente ou inválido, a validação falhará e o Doctor informará o erro do plugin.
• Se houver configuração para um plugin, mas ele estiver desativado, a configuração será mantida e um aviso será exibido no Doctor e nos logs.

Consulte a Referência de configuração para ver o schema completo de plugins.*.

Observações

• O manifesto é obrigatório para plugins nativos do OpenClaw, incluindo carregamentos do sistema de arquivos local. O runtime ainda carrega o módulo do plugin separadamente; o manifesto serve apenas para descoberta e validação.
• Manifestos nativos são analisados com JSON5; portanto, comentários, vírgulas finais e chaves sem aspas são aceitos, desde que o valor final ainda seja um objeto.
• Somente os campos documentados do manifesto são lidos pelo carregador de manifestos. Evite chaves personalizadas no nível superior.
• channels, providers, cliBackends e skills podem ser omitidos quando um plugin não precisar deles.
• providerCatalogEntry deve permanecer leve e não deve importar código amplo de runtime; use-o para metadados estáticos do catálogo de provedores ou descritores de descoberta específicos, não para execução durante solicitações.
• Tipos exclusivos de plugins são selecionados por meio de plugins.slots.*: kind: "memory" via plugins.slots.memory (padrão: memory-core) e kind: "context-engine" via plugins.slots.contextEngine (padrão: legacy).
• Declare o tipo exclusivo do plugin neste manifesto. OpenClawPluginDefinition.kind da entrada de runtime foi descontinuado e permanece apenas como fallback de compatibilidade para plugins mais antigos.
• Os metadados de variáveis de ambiente (setup.providers[].envVars, o obsoleto providerAuthEnvVars e channelEnvVars) são apenas declarativos. O status, a auditoria, a validação de entrega do Cron e outras superfícies somente leitura ainda aplicam a confiança do plugin e a política de ativação efetiva antes de considerar uma variável de ambiente configurada.
• Para metadados do assistente de runtime que exigem código do provedor, consulte Hooks de runtime do provedor.
• Se o seu plugin depender de módulos nativos, documente as etapas de compilação e todos os requisitos de lista de permissões do gerenciador de pacotes (por exemplo, allow-build-scripts do pnpm + pnpm rebuild <package>).

Conteúdo relacionado