Plugin मेनिफेस्ट

यह पृष्ठ केवल नेटिव OpenClaw Plugin मेनिफेस्ट के लिए है।

संगत बंडल लेआउट के लिए, Plugin बंडल देखें।

संगत बंडल फ़ॉर्मैट अलग मेनिफेस्ट फ़ाइलों का उपयोग करते हैं:

• Codex बंडल: .codex-plugin/plugin.json
• Claude बंडल: .claude-plugin/plugin.json या बिना मेनिफेस्ट वाला डिफ़ॉल्ट Claude घटक लेआउट
• Cursor बंडल: .cursor-plugin/plugin.json

OpenClaw उन बंडल लेआउट को भी स्वतः पहचानता है, लेकिन उन्हें यहाँ वर्णित openclaw.plugin.json स्कीमा के विरुद्ध सत्यापित नहीं किया जाता।

संगत बंडलों के लिए, OpenClaw वर्तमान में बंडल मेटाडेटा के साथ घोषित skill रूट, Claude कमांड रूट, Claude बंडल settings.json डिफ़ॉल्ट, Claude बंडल LSP डिफ़ॉल्ट, और समर्थित hook पैक पढ़ता है, जब लेआउट OpenClaw रनटाइम अपेक्षाओं से मेल खाता है।

हर नेटिव OpenClaw Plugin को Plugin रूट में एक openclaw.plugin.json फ़ाइल शिप करनी अनिवार्य है। OpenClaw इस मेनिफेस्ट का उपयोग Plugin कोड निष्पादित किए बिना कॉन्फ़िगरेशन सत्यापित करने के लिए करता है। अनुपस्थित या अमान्य मेनिफेस्ट को Plugin त्रुटियाँ माना जाता है और वे कॉन्फ़िग सत्यापन को रोकते हैं।

पूरा Plugin सिस्टम गाइड देखें: Plugins। नेटिव क्षमता मॉडल और वर्तमान बाहरी-संगतता मार्गदर्शन के लिए: क्षमता मॉडल।

यह फ़ाइल क्या करती है

openclaw.plugin.json वह मेटाडेटा है जिसे OpenClaw आपका Plugin कोड लोड करने से पहले पढ़ता है। नीचे दी गई हर चीज़ इतनी हल्की होनी चाहिए कि Plugin रनटाइम बूट किए बिना निरीक्षण की जा सके।

इसका उपयोग करें:

• Plugin पहचान, कॉन्फ़िग सत्यापन, और कॉन्फ़िग UI संकेतों के लिए
• auth, ऑनबोर्डिंग, और सेटअप मेटाडेटा (alias, auto-enable, provider env vars, auth choices) के लिए
• control-plane सतहों के लिए activation संकेतों के लिए
• मॉडल-फ़ैमिली स्वामित्व के शॉर्टहैंड के लिए
• स्थिर क्षमता-स्वामित्व स्नैपशॉट (contracts) के लिए
• QA runner मेटाडेटा जिसे साझा openclaw qa होस्ट निरीक्षण कर सके
• catalog और validation सतहों में merge किए गए channel-specific config metadata के लिए

इसका उपयोग न करें: रनटाइम व्यवहार रजिस्टर करने, कोड entrypoints घोषित करने, या npm install metadata के लिए। वे आपके Plugin कोड और package.json में होते हैं।

न्यूनतम उदाहरण

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

समृद्ध उदाहरण

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

शीर्ष-स्तरीय फ़ील्ड संदर्भ

जनरेशन प्रोवाइडर मेटाडेटा संदर्भ

जनरेशन प्रोवाइडर मेटाडेटा फ़ील्ड उन प्रोवाइडर के लिए स्थिर ऑथ सिग्नल बताते हैं जो संबंधित contracts.*GenerationProviders सूची में घोषित हैं। OpenClaw इन फ़ील्ड को प्रोवाइडर रनटाइम लोड होने से पहले पढ़ता है ताकि कोर टूल हर प्रोवाइडर Plugin को इंपोर्ट किए बिना तय कर सकें कि कोई जनरेशन प्रोवाइडर उपलब्ध है या नहीं।

इन फ़ील्ड का उपयोग केवल सस्ते, घोषणात्मक तथ्यों के लिए करें। ट्रांसपोर्ट, अनुरोध ट्रांसफ़ॉर्म, टोकन रिफ़्रेश, क्रेडेंशियल सत्यापन, और वास्तविक जनरेशन व्यवहार 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"]          }        }      ]    }  }}

हर मेटाडेटा एंट्री समर्थित करती है:

हर configSignals एंट्री समर्थित करती है:

हर mode गार्ड समर्थित करता है:

हर authSignals एंट्री समर्थित करती है:

हर providerBaseUrl गार्ड समर्थित करता है:

टूल मेटाडेटा संदर्भ

toolMetadata टूल नाम से की गई कुंजी के साथ, जनरेशन प्रोवाइडर मेटाडेटा जैसी ही configSignals और authSignals आकृतियों का उपयोग करता है। contracts.tools स्वामित्व घोषित करता है। toolMetadata सस्ता उपलब्धता प्रमाण घोषित करता है ताकि OpenClaw केवल अपने टूल फ़ैक्टरी से null वापस दिलाने के लिए Plugin रनटाइम इंपोर्ट करने से बच सके।

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

यदि किसी टूल के पास toolMetadata नहीं है, तो OpenClaw मौजूदा व्यवहार सुरक्षित रखता है और टूल कॉन्ट्रैक्ट पॉलिसी से मेल खाने पर स्वामित्व वाला Plugin लोड करता है। हॉट-पाथ टूल जिनकी फ़ैक्टरी ऑथ/कॉन्फ़िग पर निर्भर करती है, उनके लिए Plugin लेखकों को पूछने के लिए कोर से रनटाइम इंपोर्ट करवाने के बजाय toolMetadata घोषित करना चाहिए।

providerAuthChoices संदर्भ

हर providerAuthChoices एंट्री एक ऑनबोर्डिंग या ऑथ विकल्प बताती है। OpenClaw इसे प्रोवाइडर रनटाइम लोड होने से पहले पढ़ता है। प्रोवाइडर सेटअप सूचियाँ प्रोवाइडर रनटाइम लोड किए बिना इन मैनिफ़ेस्ट विकल्पों, डिस्क्रिप्टर-व्युत्पन्न सेटअप विकल्पों, और इंस्टॉल-कैटलॉग मेटाडेटा का उपयोग करती हैं।

commandAliases संदर्भ

commandAliases का उपयोग तब करें जब कोई Plugin ऐसा रनटाइम कमांड नाम रखता हो जिसे उपयोगकर्ता गलती से plugins.allow में डाल सकते हैं या root CLI कमांड की तरह चलाने की कोशिश कर सकते हैं। OpenClaw Plugin रनटाइम कोड आयात किए बिना निदान के लिए इस मेटाडेटा का उपयोग करता है।

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

activation संदर्भ

activation का उपयोग तब करें जब Plugin कम लागत में यह घोषित कर सकता हो कि किन नियंत्रण-प्लेन इवेंट्स में उसे सक्रियण/लोड योजना में शामिल किया जाना चाहिए।

यह ब्लॉक प्लानर मेटाडेटा है, लाइफ़साइकल API नहीं। यह रनटाइम व्यवहार पंजीकृत नहीं करता, register(...) को प्रतिस्थापित नहीं करता, और यह वादा नहीं करता कि Plugin कोड पहले ही निष्पादित हो चुका है। सक्रियण प्लानर मौजूदा मैनिफ़ेस्ट स्वामित्व मेटाडेटा जैसे providers, channels, commandAliases, setup.providers, contracts.tools, और हुक्स पर वापस जाने से पहले उम्मीदवार Plugins को सीमित करने के लिए इन फ़ील्ड्स का उपयोग करता है।

सबसे संकीर्ण मेटाडेटा को प्राथमिकता दें जो पहले से स्वामित्व का वर्णन करता हो। जब providers, channels, commandAliases, सेटअप डिस्क्रिप्टर, या contracts संबंध व्यक्त करते हों, तो उनका उपयोग करें। अतिरिक्त प्लानर संकेतों के लिए activation का उपयोग करें जिन्हें उन स्वामित्व फ़ील्ड्स से निरूपित नहीं किया जा सकता। claude-cli, my-cli, या google-gemini-cli जैसे CLI रनटाइम उपनामों के लिए शीर्ष-स्तरीय cliBackends का उपयोग करें; activation.onAgentHarnesses केवल उन एम्बेडेड एजेंट हार्नेस आईडी के लिए है जिनके पास पहले से कोई स्वामित्व फ़ील्ड नहीं है।

यह ब्लॉक केवल मेटाडेटा है। यह रनटाइम व्यवहार पंजीकृत नहीं करता, और यह register(...), setupEntry, या अन्य रनटाइम/Plugin एंट्रीपॉइंट्स को प्रतिस्थापित नहीं करता। वर्तमान उपभोक्ता व्यापक Plugin लोडिंग से पहले इसे सीमित करने वाले संकेत के रूप में उपयोग करते हैं, इसलिए गैर-स्टार्टअप सक्रियण मेटाडेटा का न होना आम तौर पर केवल प्रदर्शन की लागत बनता है; जब तक मैनिफ़ेस्ट स्वामित्व फॉलबैक अभी भी मौजूद हैं, इससे शुद्धता नहीं बदलनी चाहिए।

हर Plugin को activation.onStartup जानबूझकर सेट करना चाहिए। इसे true केवल तब सेट करें जब Plugin को Gateway स्टार्टअप के दौरान चलना ही हो। इसे false तब सेट करें जब Plugin स्टार्टअप पर निष्क्रिय हो और केवल संकीर्ण ट्रिगर्स से लोड होना चाहिए। onStartup छोड़ देने से अब Plugin परोक्ष रूप से स्टार्टअप-लोड नहीं होता; स्टार्टअप, चैनल, कॉन्फ़िग, एजेंट-हार्नेस, मेमोरी, या अन्य संकीर्ण सक्रियण ट्रिगर्स के लिए स्पष्ट सक्रियण मेटाडेटा का उपयोग करें।

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

वर्तमान लाइव उपभोक्ता:

• Gateway स्टार्टअप योजना स्पष्ट स्टार्टअप आयात के लिए activation.onStartup का उपयोग करती है
• कमांड-ट्रिगर वाली CLI योजना पुराने commandAliases[].cliCommand या commandAliases[].name पर वापस जाती है
• एजेंट-रनटाइम स्टार्टअप योजना एम्बेडेड हार्नेस के लिए activation.onAgentHarnesses और CLI रनटाइम उपनामों के लिए शीर्ष-स्तरीय cliBackends[] का उपयोग करती है
• चैनल-ट्रिगर सेटअप/चैनल योजना स्पष्ट चैनल सक्रियण मेटाडेटा न होने पर पुराने channels[] स्वामित्व पर वापस जाती है
• स्टार्टअप Plugin योजना bundled ब्राउज़र Plugin के browser ब्लॉक जैसी गैर-चैनल root कॉन्फ़िग सतहों के लिए activation.onConfigPaths का उपयोग करती है
• प्रदाता-ट्रिगर सेटअप/रनटाइम योजना स्पष्ट प्रदाता सक्रियण मेटाडेटा न होने पर पुराने providers[] और शीर्ष-स्तरीय cliBackends[] स्वामित्व पर वापस जाती है

प्लानर निदान स्पष्ट सक्रियण संकेतों को मैनिफ़ेस्ट स्वामित्व फॉलबैक से अलग कर सकते हैं। उदाहरण के लिए, activation-command-hint का अर्थ है कि activation.onCommands मिला, जबकि manifest-command-alias का अर्थ है कि प्लानर ने इसके बजाय commandAliases स्वामित्व का उपयोग किया। ये कारण लेबल होस्ट निदान और परीक्षणों के लिए हैं; Plugin लेखकों को वह मेटाडेटा घोषित करते रहना चाहिए जो स्वामित्व का सबसे अच्छा वर्णन करता है।

qaRunners संदर्भ

qaRunners का उपयोग तब करें जब कोई Plugin साझा openclaw qa root के नीचे एक या अधिक ट्रांसपोर्ट रनर योगदान करता हो। इस मेटाडेटा को सस्ता और स्थिर रखें; Plugin रनटाइम अभी भी हल्के runtime-api.ts सतह के माध्यम से वास्तविक CLI पंजीकरण का स्वामी है जो qaRunnerCliRegistrations निर्यात करती है।

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

setup संदर्भ

जब सेटअप और ऑनबोर्डिंग सतहों को रनटाइम लोड होने से पहले सस्ते Plugin-स्वामित्व वाले मेटाडेटा की आवश्यकता हो, तब setup का उपयोग करें।

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

शीर्ष-स्तरीय cliBackends वैध रहता है और CLI अनुमान बैकएंड का वर्णन करना जारी रखता है। setup.cliBackends उन कंट्रोल-प्लेन/setup फ़्लो के लिए सेटअप-विशिष्ट वर्णनकर्ता सतह है जिन्हें केवल-मेटाडेटा रहना चाहिए।

मौजूद होने पर, setup.providers और setup.cliBackends सेटअप खोज के लिए पसंदीदा वर्णनकर्ता-प्रथम लुकअप सतह हैं। यदि वर्णनकर्ता केवल उम्मीदवार Plugin को सीमित करता है और सेटअप को अभी भी अधिक समृद्ध सेटअप-समय रनटाइम हुक की आवश्यकता है, तो requiresRuntime: true सेट करें और फ़ॉलबैक निष्पादन पथ के रूप में setup-api को बनाए रखें।

OpenClaw सामान्य प्रदाता प्रमाणीकरण और पर्यावरण-चर लुकअप में setup.providers[].envVars भी शामिल करता है। providerAuthEnvVars अवमूल्यन विंडो के दौरान संगतता अडैप्टर के माध्यम से समर्थित रहता है, लेकिन जो गैर-बंडल Plugins अभी भी इसका उपयोग करते हैं उन्हें मैनिफ़ेस्ट डायग्नोस्टिक मिलता है। नए Plugins को सेटअप/स्थिति पर्यावरण मेटाडेटा setup.providers[].envVars पर रखना चाहिए।

जब कोई सेटअप प्रविष्टि उपलब्ध न हो, या जब setup.requiresRuntime: false सेटअप रनटाइम को अनावश्यक घोषित करता हो, तब OpenClaw setup.providers[].authMethods से सरल सेटअप विकल्प भी निकाल सकता है। स्पष्ट providerAuthChoices प्रविष्टियां कस्टम लेबल, CLI फ़्लैग, ऑनबोर्डिंग स्कोप, और सहायक मेटाडेटा के लिए पसंदीदा रहती हैं।

requiresRuntime: false केवल तब सेट करें जब वे वर्णनकर्ता सेटअप सतह के लिए पर्याप्त हों। OpenClaw स्पष्ट false को केवल-वर्णनकर्ता अनुबंध मानता है और सेटअप लुकअप के लिए setup-api या openclaw.setupEntry निष्पादित नहीं करेगा। यदि केवल-वर्णनकर्ता Plugin फिर भी उन सेटअप रनटाइम प्रविष्टियों में से एक भेजता है, तो OpenClaw एक योगात्मक डायग्नोस्टिक रिपोर्ट करता है और उसे अनदेखा करना जारी रखता है। छोड़ा गया requiresRuntime विरासत फ़ॉलबैक व्यवहार बनाए रखता है ताकि जिन मौजूदा Plugins ने फ़्लैग के बिना वर्णनकर्ता जोड़े थे, वे टूटें नहीं।

क्योंकि सेटअप लुकअप Plugin-स्वामित्व वाला setup-api कोड निष्पादित कर सकता है, सामान्यीकृत setup.providers[].id और setup.cliBackends[] मान खोजे गए Plugins में अद्वितीय रहने चाहिए। अस्पष्ट स्वामित्व खोज क्रम से विजेता चुनने के बजाय बंद होकर विफल होता है।

जब सेटअप रनटाइम निष्पादित होता है, सेटअप रजिस्ट्री डायग्नोस्टिक्स वर्णनकर्ता बहाव रिपोर्ट करते हैं यदि setup-api कोई ऐसा प्रदाता या CLI बैकएंड पंजीकृत करता है जिसे मैनिफ़ेस्ट वर्णनकर्ता घोषित नहीं करते, या यदि किसी वर्णनकर्ता का मेल खाता रनटाइम पंजीकरण नहीं है। ये डायग्नोस्टिक्स योगात्मक हैं और विरासत Plugins को अस्वीकार नहीं करते।

setup.providers संदर्भ

authEvidence प्रदाता-स्वामित्व वाले स्थानीय क्रेडेंशियल मार्कर के लिए है जिन्हें रनटाइम कोड लोड किए बिना सत्यापित किया जा सकता है। ये जांचें सस्ती और स्थानीय रहनी चाहिए: कोई नेटवर्क कॉल नहीं, कोई कीचेन या सीक्रेट-मैनेजर रीड नहीं, कोई शेल कमांड नहीं, और कोई प्रदाता API जांच नहीं।

समर्थित साक्ष्य प्रविष्टियां:

setup फ़ील्ड

uiHints संदर्भ

uiHints कॉन्फ़िग फ़ील्ड नामों से छोटे रेंडरिंग संकेतों तक का मैप है।

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

प्रत्येक फ़ील्ड संकेत में ये शामिल हो सकते हैं:

contracts संदर्भ

contracts का उपयोग केवल स्थिर क्षमता स्वामित्व मेटाडेटा के लिए करें जिसे OpenClaw 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"],    "webFetchProviders": ["firecrawl"],    "webSearchProviders": ["gemini"],    "migrationProviders": ["hermes"],    "gatewayMethodDispatch": ["authenticated-request"],    "tools": ["firecrawl_search", "firecrawl_scrape"]  }}

प्रत्येक सूची वैकल्पिक है:

contracts.embeddedExtensionFactories को बंडल किए गए Codex केवल app-server extension factories के लिए बनाए रखा गया है। बंडल किए गए tool-result transforms को इसके बजाय contracts.agentToolResultMiddleware घोषित करना चाहिए और api.registerAgentToolResultMiddleware(...) के साथ पंजीकृत करना चाहिए। इंस्टॉल किए गए Plugins उसी middleware seam का उपयोग केवल तभी कर सकते हैं जब उसे स्पष्ट रूप से सक्षम किया गया हो और केवल उन runtimes के लिए जिन्हें वे contracts.agentToolResultMiddleware में घोषित करते हैं।

जिन इंस्टॉल किए गए Plugins को host-trusted pre-tool policy tier की आवश्यकता है, उन्हें contracts.trustedToolPolicies में प्रत्येक पंजीकृत local id घोषित करनी होगी और स्पष्ट रूप से सक्षम होना होगा। बंडल किए गए Plugins मौजूदा trusted-policy path बनाए रखते हैं, लेकिन इंस्टॉल किए गए Plugins जिनके policy ids घोषित नहीं हैं, पंजीकरण से पहले अस्वीकार कर दिए जाते हैं। Policy ids पंजीकरण करने वाले Plugin के scope में होते हैं, इसलिए दो Plugins दोनों workflow-budget घोषित और पंजीकृत कर सकते हैं; एक ही Plugin उसी local id को दो बार पंजीकृत नहीं कर सकता।

Runtime api.registerTool(...) registrations को contracts.tools से मेल खाना चाहिए। Tool discovery इस सूची का उपयोग केवल उन Plugin runtimes को लोड करने के लिए करती है जो अनुरोधित tools के स्वामी हो सकते हैं।

Provider Plugins जो resolveExternalAuthProfiles लागू करते हैं, उन्हें contracts.externalAuthProviders घोषित करना चाहिए; अघोषित external-auth hooks अनदेखे किए जाते हैं।

सामान्य embedding providers को api.registerEmbeddingProvider(...) के साथ पंजीकृत प्रत्येक adapter के लिए contracts.embeddingProviders घोषित करना चाहिए। पुन: प्रयोज्य vector generation के लिए सामान्य contract का उपयोग करें, जिसमें memory search द्वारा उपयोग किए गए providers शामिल हैं। contracts.memoryEmbeddingProviders deprecated memory-विशिष्ट compatibility है और केवल तब तक बनी रहती है जब तक मौजूदा providers generic embedding provider seam पर migrate नहीं हो जाते।

contracts.gatewayMethodDispatch वर्तमान में "authenticated-request" स्वीकार करता है। यह native Plugin HTTP routes के लिए एक API hygiene gate है, जो जानबूझकर Gateway control-plane methods को process के भीतर dispatch करते हैं; यह malicious native Plugins के विरुद्ध sandbox नहीं है। इसे केवल कड़ाई से समीक्षा किए गए बंडल किए गए/operator surfaces के लिए उपयोग करें जिन्हें पहले से Gateway HTTP auth की आवश्यकता होती है।

mediaUnderstandingProviderMetadata संदर्भ

mediaUnderstandingProviderMetadata का उपयोग तब करें जब किसी media-understanding provider के पास default models, auto-auth fallback priority, या native document support हो जिसकी generic core helpers को runtime loads से पहले आवश्यकता होती है। Keys को contracts.mediaUnderstandingProviders में भी घोषित किया जाना चाहिए।

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

प्रत्येक provider entry में ये शामिल हो सकते हैं:

channelConfigs संदर्भ

channelConfigs का उपयोग तब करें जब किसी channel Plugin को runtime loads से पहले सस्ती config metadata की आवश्यकता हो। Read-only channel setup/status discovery इस metadata का सीधे उपयोग configured external channels के लिए कर सकती है जब कोई setup entry उपलब्ध न हो, या जब setup.requiresRuntime: false setup runtime को अनावश्यक घोषित करता है।

channelConfigs Plugin manifest metadata है, कोई नया top-level user config section नहीं। Users अभी भी channel instances को channels.<channel-id> के अंतर्गत configure करते हैं। OpenClaw manifest metadata पढ़ता है ताकि तय कर सके कि Plugin runtime code execute होने से पहले उस configured channel का स्वामी कौन सा Plugin है।

किसी channel Plugin के लिए, configSchema और channelConfigs अलग paths का वर्णन करते हैं:

• configSchema plugins.entries.<plugin-id>.config को validate करता है
• channelConfigs.<channel-id>.schema channels.<channel-id> को validate करता है

Non-bundled Plugins जो channels[] घोषित करते हैं, उन्हें matching channelConfigs entries भी घोषित करनी चाहिए। इनके बिना, OpenClaw अभी भी Plugin load कर सकता है, लेकिन cold-path config schema, setup, और Control UI surfaces Plugin runtime execute होने तक channel-owned option shape नहीं जान सकते।

channelConfigs.<channel-id>.commands.nativeCommandsAutoEnabled और nativeSkillsAutoEnabled command config checks के लिए static auto defaults घोषित कर सकते हैं जो channel runtime loads से पहले चलते हैं। बंडल किए गए channels भी अपने अन्य package-owned channel catalog metadata के साथ package.json#openclaw.channel.commands के माध्यम से वही defaults publish कर सकते हैं।

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

प्रत्येक channel entry में ये शामिल हो सकते हैं:

किसी अन्य channel Plugin को बदलना

preferOver का उपयोग तब करें जब आपका Plugin किसी channel id के लिए preferred owner हो जिसे कोई दूसरा Plugin भी provide कर सकता है। सामान्य cases हैं renamed Plugin id, standalone Plugin जो किसी bundled Plugin को supersede करता है, या maintained fork जो config compatibility के लिए वही channel id रखता है।

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

जब channels.chat configured होता है, OpenClaw channel id और preferred Plugin id दोनों पर विचार करता है। यदि lower-priority Plugin केवल इसलिए selected था क्योंकि वह bundled है या default रूप से enabled है, तो OpenClaw उसे effective runtime config में disabled कर देता है ताकि एक Plugin channel और उसके tools का स्वामी हो। Explicit user selection अभी भी जीतता है: यदि user दोनों Plugins को स्पष्ट रूप से enable करता है, तो OpenClaw उस choice को preserve करता है और requested Plugin set को silently बदलने के बजाय duplicate channel/tool diagnostics report करता है।

preferOver को उन Plugin ids तक scoped रखें जो सच में वही channel provide कर सकते हैं। यह कोई general priority field नहीं है और यह user config keys को rename नहीं करता।

modelSupport संदर्भ

जब OpenClaw को plugin runtime लोड होने से पहले gpt-5.5 या claude-sonnet-4.6 जैसे शॉर्टहैंड मॉडल id से आपके provider plugin का अनुमान लगाना हो, तब modelSupport का उपयोग करें।

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

OpenClaw यह प्राथमिकता लागू करता है:

• स्पष्ट provider/model refs मालिकाना providers manifest metadata का उपयोग करते हैं
• modelPatterns, modelPrefixes से पहले लागू होते हैं
• अगर एक non-bundled plugin और एक bundled plugin, दोनों मेल खाते हैं, तो non-bundled plugin जीतता है
• बाकी अस्पष्टता को तब तक अनदेखा किया जाता है जब तक user या config कोई provider निर्दिष्ट नहीं करता

फ़ील्ड:

modelPatterns entries को compileSafeRegex के माध्यम से compile किया जाता है, जो nested repetition वाले patterns को अस्वीकार करता है (उदाहरण के लिए (a+)+$)। safety check में असफल होने वाले patterns को चुपचाप छोड़ दिया जाता है, ठीक वैसे ही जैसे syntactically invalid regex। patterns को सरल रखें और nested quantifiers से बचें।

modelCatalog reference

जब OpenClaw को plugin runtime लोड करने से पहले provider model metadata जानना हो, तब modelCatalog का उपयोग करें। यह fixed catalog rows, provider aliases, suppression rules, और discovery mode के लिए manifest-owned source है। Runtime refresh अभी भी provider runtime code में रहता है, लेकिन manifest core को बताता है कि runtime कब आवश्यक है।

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

शीर्ष-स्तरीय फ़ील्ड:

aliases model-catalog planning के लिए provider ownership lookup में भाग लेता है। Alias targets उसी plugin के स्वामित्व वाले शीर्ष-स्तरीय providers होने चाहिए। जब कोई provider-filtered list alias का उपयोग करती है, तो OpenClaw owning manifest पढ़ सकता है और provider runtime लोड किए बिना alias API/base URL overrides लागू कर सकता है। Aliases unfiltered catalog listings को expand नहीं करते; broad lists केवल owning canonical provider rows emit करते हैं।

suppressions पुराने provider runtime suppressBuiltInModel hook को प्रतिस्थापित करता है। Suppression entries को केवल तब माना जाता है जब provider plugin के स्वामित्व में हो या modelCatalog.aliases key के रूप में घोषित हो जो किसी owned provider को target करती है। Runtime suppression hooks को अब model resolution के दौरान call नहीं किया जाता।

Provider फ़ील्ड:

Model फ़ील्ड:

Suppression फ़ील्ड:

modelCatalog में runtime-only data न डालें। static का उपयोग केवल तब करें जब manifest rows provider-filtered list और picker surfaces के लिए registry/runtime discovery छोड़ने हेतु काफ़ी पूर्ण हों। refreshable का उपयोग तब करें जब manifest rows उपयोगी listable seeds या supplements हों, लेकिन refresh/cache बाद में और rows जोड़ सके; refreshable rows अपने आप में authoritative नहीं होते। runtime का उपयोग तब करें जब OpenClaw को list जानने के लिए provider runtime लोड करना ही हो।

modelIdNormalization reference

modelIdNormalization का उपयोग cheap provider-owned model-id cleanup के लिए करें जिसे provider runtime लोड होने से पहले होना चाहिए। यह short model names, provider-local legacy ids, और proxy prefix rules जैसे aliases को core model-selection tables के बजाय owning plugin manifest में रखता है।

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

Provider फ़ील्ड:

providerEndpoints reference

generic request policy को provider runtime लोड होने से पहले जिस endpoint classification को जानना हो, उसके लिए providerEndpoints का उपयोग करें। Core अभी भी प्रत्येक endpointClass का अर्थ own करता है; plugin manifests host और base URL metadata own करते हैं।

एंडपॉइंट फ़ील्ड:

providerRequest संदर्भ

सस्ते अनुरोध-संगतता मेटाडेटा के लिए providerRequest का उपयोग करें, जिसकी सामान्य अनुरोध नीति को provider runtime लोड किए बिना आवश्यकता होती है। व्यवहार-विशिष्ट payload rewriting को provider runtime hooks या साझा provider-family helpers में रखें।

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

Provider फ़ील्ड:

secretProviderIntegrations संदर्भ

जब कोई plugin पुन: उपयोग योग्य SecretRef exec provider preset प्रकाशित कर सकता है, तब secretProviderIntegrations का उपयोग करें। OpenClaw plugin runtime लोड होने से पहले यह मेटाडेटा पढ़ता है, secrets.providers.<alias>.pluginIntegration में plugin ownership संग्रहीत करता है, और वास्तविक secret resolution को SecretRef runtime पर छोड़ता है। Presets केवल bundled plugins और managed plugin install roots से खोजे गए installed plugins के लिए उजागर होते हैं, जैसे git और ClawHub installs।

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

map key integration id है। यदि providerAlias छोड़ दिया गया है, तो OpenClaw integration id को SecretRef provider alias के रूप में उपयोग करता है। Provider aliases को सामान्य SecretRef provider alias pattern से मेल खाना चाहिए, उदाहरण के लिए team-secrets या onepassword-work।

जब कोई operator preset चुनता है, तो OpenClaw इस तरह provider reference लिखता है:

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

startup/reload पर, OpenClaw वर्तमान plugin manifest metadata लोड करके, owning plugin installed और active है यह जाँचकर, और manifest से exec command materialize करके उस provider को resolve करता है। plugin को disable या remove करने से active SecretRefs के लिए provider revoked हो जाता है। जो operators standalone exec configuration चाहते हैं, वे अभी भी manual command/args providers सीधे लिख सकते हैं।

वर्तमान में केवल source: "exec" presets समर्थित हैं। command को ${node} होना चाहिए, और args[0] को ./ plugin-root-relative resolver script होना चाहिए। OpenClaw इसे startup/reload पर वर्तमान Node executable और absolute in-plugin script path में materialize करता है। Node options जैसे --require, --import, --loader, --env-file, --eval, और --print manifest preset contract का हिस्सा नहीं हैं। जिन operators को non-Node commands चाहिए, वे standalone manual exec providers सीधे configure कर सकते हैं।

OpenClaw manifest presets के लिए trustedDirs को plugin root से और, ${node} presets के लिए, वर्तमान Node executable directory से derive करता है। Manifest-authored trustedDirs अनदेखे किए जाते हैं। अन्य exec provider options जैसे timeoutMs, maxOutputBytes, jsonOnly, env, passEnv, और allowInsecurePath सामान्य SecretRef exec provider config तक pass through होते हैं।

modelPricing संदर्भ

जब किसी provider को runtime load होने से पहले control-plane pricing behavior की आवश्यकता हो, तब modelPricing का उपयोग करें। Gateway pricing cache provider runtime code import किए बिना यह metadata पढ़ता है।

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

Provider फ़ील्ड:

Source फ़ील्ड:

OpenClaw Provider Index

OpenClaw Provider Index उन providers के लिए OpenClaw-owned preview metadata है जिनके plugins अभी installed नहीं हो सकते। यह plugin manifest का हिस्सा नहीं है। Plugin manifests installed-plugin authority बने रहते हैं। Provider Index वह internal fallback contract है जिसका उपयोग भविष्य के installable-provider और pre-install model picker surfaces तब करेंगे जब कोई provider plugin installed नहीं होगा।

Catalog authority order:

1. User config।
2. Installed plugin manifest modelCatalog।
3. Explicit refresh से model catalog cache।
4. OpenClaw Provider Index preview rows।

Provider Index में secrets, enabled state, runtime hooks, या live account-specific model data नहीं होना चाहिए। इसके preview catalogs वही modelCatalog provider row shape उपयोग करते हैं जो plugin manifests करते हैं, लेकिन इन्हें stable display metadata तक सीमित रहना चाहिए, जब तक runtime adapter fields जैसे api, baseUrl, pricing, या compatibility flags को जानबूझकर installed plugin manifest के साथ aligned न रखा गया हो। Live /models discovery वाले providers को सामान्य listing या onboarding के दौरान provider APIs call करने के बजाय explicit model catalog cache path के जरिए refreshed rows लिखनी चाहिए।

Provider Index entries उन providers के लिए installable-plugin metadata भी रख सकती हैं जिनका plugin core से बाहर चला गया है या अन्यथा अभी installed नहीं है। यह metadata channel catalog pattern को mirror करता है: package name, npm install spec, expected integrity, और cheap auth-choice labels किसी installable setup option को दिखाने के लिए पर्याप्त हैं। Plugin installed हो जाने पर, उसका manifest जीतता है और उस provider के लिए Provider Index entry अनदेखी की जाती है।

Legacy top-level capability keys deprecated हैं। speechProviders, realtimeTranscriptionProviders, realtimeVoiceProviders, mediaUnderstandingProviders, imageGenerationProviders, videoGenerationProviders, webFetchProviders, और webSearchProviders को contracts के अंतर्गत ले जाने के लिए openclaw doctor --fix का उपयोग करें; सामान्य manifest loading अब उन top-level fields को capability ownership के रूप में नहीं मानती।

Manifest बनाम package.json

दोनों files अलग-अलग काम करती हैं:

यदि आप निश्चित नहीं हैं कि metadata का कोई हिस्सा कहाँ होना चाहिए, तो यह नियम उपयोग करें:

• यदि OpenClaw को plugin code load करने से पहले इसे जानना आवश्यक है, तो इसे openclaw.plugin.json में रखें
• यदि यह packaging, entry files, या npm install behavior के बारे में है, तो इसे package.json में रखें

package.json fields जो discovery को प्रभावित करते हैं

कुछ pre-runtime plugin metadata जानबूझकर openclaw.plugin.json के बजाय package.json में openclaw block के अंतर्गत रहता है। openclaw.bundle और openclaw.bundle.json OpenClaw plugin contracts नहीं हैं; native plugins को openclaw.plugin.json और नीचे दिए गए समर्थित package.json#openclaw fields का उपयोग करना चाहिए।

महत्वपूर्ण उदाहरण:

Manifest metadata तय करता है कि runtime लोड होने से पहले onboarding में कौन-से provider/channel/setup विकल्प दिखते हैं। package.json#openclaw.install onboarding को बताता है कि जब user उन विकल्पों में से एक चुनता है तो उस Plugin को कैसे fetch या enable करना है। install hints को openclaw.plugin.json में न ले जाएं।

openclaw.install.minHostVersion non-bundled Plugin sources के लिए install और manifest registry loading के दौरान enforce किया जाता है। अमान्य values reject की जाती हैं; newer-but-valid values पुराने hosts पर external Plugins को skip करती हैं। Bundled source Plugins को host checkout के साथ co-versioned माना जाता है।

openclaw.install.requiredPlatformPackages उन npm packages के लिए है जो optional, platform-specific aliases के माध्यम से आवश्यक native binaries expose करते हैं। हर supported platform alias के लिए bare npm package name list करें। npm install के दौरान, OpenClaw केवल उस declared alias को verify करता है जिसके lockfile constraints मौजूदा host से मेल खाते हैं। यदि npm success report करता है लेकिन वह alias omit करता है, तो OpenClaw fresh cache के साथ एक बार retry करता है और alias फिर भी missing हो तो install को roll back करता है।

openclaw.compat.pluginApi non-bundled Plugin sources के लिए package install के दौरान enforce किया जाता है। इसे उस OpenClaw plugin SDK/runtime API floor के लिए उपयोग करें जिसके विरुद्ध package बनाया गया था। यह minHostVersion से stricter हो सकता है जब किसी Plugin package को newer API चाहिए लेकिन दूसरे flows के लिए lower install hint रखा जाता है। Official OpenClaw release sync default रूप से existing official Plugin API floors को OpenClaw release version तक bump करता है, लेकिन plugin-only releases lower floor रख सकते हैं जब package जानबूझकर older hosts को support करता हो। compatibility contract के रूप में केवल package version का उपयोग न करें। peerDependencies.openclaw npm package metadata बना रहता है; OpenClaw install compatibility decisions के लिए openclaw.compat.pluginApi contract का उपयोग करता है।

Official install-on-demand metadata को clawhubSpec का उपयोग करना चाहिए जब Plugin ClawHub पर published हो; onboarding उसे preferred remote source मानता है और install के बाद ClawHub artifact facts record करता है। npmSpec उन packages के लिए compatibility fallback बना रहता है जो अभी ClawHub पर move नहीं हुए हैं।

Exact npm version pinning पहले से npmSpec में रहती है, उदाहरण के लिए "npmSpec": "@wecom/wecom-openclaw-plugin@1.2.3"। Official external catalog entries को exact specs के साथ expectedIntegrity pair करना चाहिए ताकि update flows fail closed हों यदि fetched npm artifact अब pinned release से मेल नहीं खाता। Interactive onboarding compatibility के लिए trusted registry npm specs अब भी offer करता है, जिनमें bare package names और dist-tags शामिल हैं। Catalog diagnostics exact, floating, integrity-pinned, missing-integrity, package-name mismatch, और invalid default-choice sources में अंतर कर सकते हैं। वे तब भी warn करते हैं जब expectedIntegrity मौजूद हो लेकिन कोई valid npm source नहीं हो जिसे वह pin कर सके। जब expectedIntegrity मौजूद हो, install/update flows उसे enforce करते हैं; जब वह omitted हो, registry resolution integrity pin के बिना record किया जाता है।

Channel Plugins को openclaw.setupEntry देना चाहिए जब status, channel list, या SecretRef scans को पूरा runtime लोड किए बिना configured accounts identify करने की जरूरत हो। setup entry को channel metadata के साथ setup-safe config, status, और secrets adapters expose करने चाहिए; network clients, gateway listeners, और transport runtimes को main extension entrypoint में रखें।

Runtime entrypoint fields source entrypoint fields के लिए package-boundary checks को override नहीं करते। उदाहरण के लिए, openclaw.runtimeExtensions किसी escaping openclaw.extensions path को loadable नहीं बना सकता।

openclaw.install.allowInvalidConfigRecovery जानबूझकर संकीर्ण है। यह arbitrary broken configs को installable नहीं बनाता। आज यह केवल install flows को specific stale bundled-plugin upgrade failures से recover करने देता है, जैसे missing bundled Plugin path या उसी bundled Plugin के लिए stale channels.<id> entry। Unrelated config errors अब भी install block करते हैं और operators को openclaw doctor --fix पर भेजते हैं।

openclaw.channel.persistedAuthState एक tiny checker module के लिए package metadata है:

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

इसे तब उपयोग करें जब setup, doctor, status, या read-only presence flows को पूरा channel Plugin लोड होने से पहले cheap yes/no auth probe चाहिए। Persisted auth state configured channel state नहीं है: इस metadata का उपयोग Plugins को auto-enable करने, runtime dependencies repair करने, या यह तय करने के लिए न करें कि channel runtime load होना चाहिए या नहीं। target export एक small function होना चाहिए जो केवल persisted state पढ़ता हो; इसे full channel runtime barrel के through route न करें।

openclaw.channel.configuredState cheap env-only configured checks के लिए वही shape follow करता है:

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

इसे तब उपयोग करें जब कोई channel env या अन्य tiny non-runtime inputs से configured-state का उत्तर दे सकता हो। यदि check को full config resolution या real channel runtime चाहिए, तो उस logic को Plugin config.hasConfiguredState hook में ही रखें।

Discovery precedence (duplicate plugin ids)

OpenClaw कई roots से Plugins discover करता है। raw filesystem scan order के लिए, Plugin scan order देखें। यदि दो discoveries का समान id है, तो केवल highest-precedence manifest रखा जाता है; lower-precedence duplicates को साथ में लोड करने के बजाय drop कर दिया जाता है।

Precedence, highest to lowest:

1. Config-selected — plugins.entries.<id> में स्पष्ट रूप से pinned path
2. Bundled — OpenClaw के साथ shipped Plugins
3. Global install — global OpenClaw Plugin root में installed Plugins
4. Workspace — मौजूदा workspace के relative discover किए गए Plugins

Implications:

• workspace में पड़ी bundled Plugin की forked या stale copy bundled build को shadow नहीं करेगी।
• bundled Plugin को local one से सच में override करने के लिए, उसे plugins.entries.<id> के जरिए pin करें ताकि वह workspace discovery पर निर्भर रहने के बजाय precedence से जीते।
• Duplicate drops log किए जाते हैं ताकि Doctor और startup diagnostics discarded copy की ओर point कर सकें।
• Config-selected duplicate overrides diagnostics में explicit overrides के रूप में word किए जाते हैं, लेकिन फिर भी warn करते हैं ताकि stale forks और accidental shadows visible रहें।

JSON Schema requirements

• हर Plugin को JSON Schema के साथ शिप होना चाहिए, भले ही वह कोई कॉन्फ़िग स्वीकार न करता हो।
• खाली स्कीमा स्वीकार्य है (उदाहरण के लिए, { "type": "object", "additionalProperties": false })।
• स्कीमा रनटाइम पर नहीं, बल्कि कॉन्फ़िग पढ़ने/लिखने के समय सत्यापित किए जाते हैं।
• नए कॉन्फ़िग कुंजियों के साथ किसी बंडल किए गए Plugin को विस्तारित या फ़ोर्क करते समय, उसी समय उस Plugin के openclaw.plugin.json configSchema को अपडेट करें। बंडल किए गए Plugin स्कीमा सख्त होते हैं, इसलिए configSchema.properties में myNewKey जोड़े बिना उपयोगकर्ता कॉन्फ़िग में plugins.entries.<id>.config.myNewKey जोड़ना Plugin रनटाइम लोड होने से पहले अस्वीकार कर दिया जाएगा।

उदाहरण स्कीमा एक्सटेंशन:

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

सत्यापन व्यवहार

• अज्ञात channels.* कुंजियाँ त्रुटियाँ हैं, जब तक चैनल id को किसी Plugin मेनिफ़ेस्ट द्वारा घोषित न किया गया हो।
• plugins.entries.<id>, plugins.allow, plugins.deny, और plugins.slots.* को खोजे जा सकने वाले Plugin ids का संदर्भ देना चाहिए। अज्ञात ids त्रुटियाँ हैं।
• यदि कोई Plugin इंस्टॉल है लेकिन उसका मेनिफ़ेस्ट या स्कीमा टूटा हुआ या अनुपस्थित है, तो सत्यापन विफल हो जाता है और Doctor Plugin त्रुटि रिपोर्ट करता है।
• यदि Plugin कॉन्फ़िग मौजूद है लेकिन Plugin अक्षम है, तो कॉन्फ़िग रखा जाता है और Doctor + लॉग में एक चेतावनी दिखाई जाती है।

पूर्ण plugins.* स्कीमा के लिए कॉन्फ़िगरेशन संदर्भ देखें।

नोट्स

• मेनिफ़ेस्ट मूल OpenClaw Plugin के लिए आवश्यक है, जिसमें स्थानीय फ़ाइल सिस्टम लोड भी शामिल हैं। रनटाइम फिर भी Plugin मॉड्यूल को अलग से लोड करता है; मेनिफ़ेस्ट केवल खोज + सत्यापन के लिए है।
• मूल मेनिफ़ेस्ट JSON5 के साथ पार्स किए जाते हैं, इसलिए टिप्पणियाँ, trailing commas, और unquoted keys तब तक स्वीकार किए जाते हैं जब तक अंतिम मान अभी भी एक ऑब्जेक्ट हो।
• मेनिफ़ेस्ट लोडर केवल दस्तावेज़ित मेनिफ़ेस्ट फ़ील्ड पढ़ता है। कस्टम शीर्ष-स्तरीय कुंजियों से बचें।
• जब किसी Plugin को उनकी आवश्यकता न हो, तो channels, providers, cliBackends, और skills सभी छोड़े जा सकते हैं।
• providerCatalogEntry हल्का रहना चाहिए और व्यापक रनटाइम कोड आयात नहीं करना चाहिए; इसे स्थिर provider catalog मेटाडेटा या संकीर्ण खोज डिस्क्रिप्टर के लिए उपयोग करें, request-time execution के लिए नहीं।
• विशिष्ट Plugin प्रकार plugins.slots.* के माध्यम से चुने जाते हैं: plugins.slots.memory के माध्यम से kind: "memory", plugins.slots.contextEngine के माध्यम से kind: "context-engine" (डिफ़ॉल्ट legacy)।
• इस मेनिफ़ेस्ट में विशिष्ट Plugin प्रकार घोषित करें। Runtime-entry OpenClawPluginDefinition.kind deprecated है और पुराने Plugin के लिए केवल compatibility fallback के रूप में रहता है।
• Env-var मेटाडेटा (setup.providers[].envVars, deprecated providerAuthEnvVars, और channelEnvVars) केवल घोषणात्मक है। Status, audit, Cron delivery validation, और अन्य read-only surfaces अभी भी किसी env var को configured मानने से पहले Plugin trust और effective activation policy लागू करते हैं।
• provider code की आवश्यकता वाले runtime wizard metadata के लिए, Provider runtime hooks देखें।
• यदि आपका Plugin native modules पर निर्भर करता है, तो build steps और किसी भी package-manager allowlist आवश्यकताओं का दस्तावेज़ बनाएं (उदाहरण के लिए, pnpm allow-build-scripts + pnpm rebuild <package>)।

संबंधित