مانیفست Plugin

این صفحه فقط برای مانیفست بومی Plugin در OpenClaw است.

برای چیدمان‌های بسته سازگار، بسته‌های Plugin را ببینید.

قالب‌های بسته سازگار از فایل‌های مانیفست متفاوتی استفاده می‌کنند:

• بسته Codex: .codex-plugin/plugin.json
• بسته Claude: .claude-plugin/plugin.json یا چیدمان پیش‌فرض مؤلفه Claude بدون مانیفست
• بسته Cursor: .cursor-plugin/plugin.json

OpenClaw این چیدمان‌های بسته را نیز به‌طور خودکار شناسایی می‌کند، اما آن‌ها در برابر شِمای openclaw.plugin.json که اینجا توصیف شده اعتبارسنجی نمی‌شوند.

برای بسته‌های سازگار، OpenClaw در حال حاضر فراداده بسته به‌همراه ریشه‌های Skills اعلام‌شده، ریشه‌های فرمان Claude، پیش‌فرض‌های settings.json در بسته Claude، پیش‌فرض‌های LSP در بسته Claude، و بسته‌های hook پشتیبانی‌شده را زمانی می‌خواند که چیدمان با انتظارات زمان اجرای OpenClaw مطابقت داشته باشد.

هر Plugin بومی OpenClaw باید یک فایل openclaw.plugin.json را در ریشه Plugin همراه داشته باشد. OpenClaw از این مانیفست برای اعتبارسنجی پیکربندی بدون اجرای کد Plugin استفاده می‌کند. مانیفست‌های ناموجود یا نامعتبر به‌عنوان خطاهای Plugin در نظر گرفته می‌شوند و اعتبارسنجی پیکربندی را مسدود می‌کنند.

راهنمای کامل سیستم Plugin را ببینید: Plugins. برای مدل قابلیت بومی و راهنمای فعلی سازگاری خارجی: مدل قابلیت.

این فایل چه کاری انجام می‌دهد

openclaw.plugin.json فراداده‌ای است که OpenClaw پیش از بارگذاری کد Plugin شما می‌خواند. همه موارد زیر باید آن‌قدر سبک باشند که بدون راه‌اندازی زمان اجرای Plugin قابل بررسی باشند.

از آن برای این موارد استفاده کنید:

• هویت Plugin، اعتبارسنجی پیکربندی، و راهنماهای رابط کاربری پیکربندی
• فراداده احراز هویت، راه‌اندازی اولیه، و تنظیمات (نام مستعار، فعال‌سازی خودکار، متغیرهای محیطی ارائه‌دهنده، گزینه‌های احراز هویت)
• راهنماهای فعال‌سازی برای سطوح صفحه کنترل
• مالکیت کوتاه‌نویسی خانواده مدل
• نماهای ایستای مالکیت قابلیت (contracts)
• فراداده اجراکننده QA که میزبان مشترک openclaw qa بتواند بررسی کند
• فراداده پیکربندی مخصوص کانال که در کاتالوگ و سطوح اعتبارسنجی ادغام می‌شود

از آن برای این موارد استفاده نکنید: ثبت رفتار زمان اجرا، اعلام entrypointهای کد، یا فراداده نصب npm. این موارد به کد 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"],  "providerAuthEnvVars": {    "openrouter": ["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 این فیلدها را پیش از بارگذاری زمان اجرای ارائه‌دهنده می‌خواند تا ابزارهای هسته بتوانند بدون import کردن هر 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 بتواند از import کردن زمان اجرای Plugin فقط برای اینکه کارخانهٔ ابزار آن null برگرداند، اجتناب کند.

{  "providerAuthEnvVars": {    "example": ["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 باید به‌جای اینکه هسته را وادار کنند زمان اجرا را برای پرس‌وجو import کند، toolMetadata را اعلام کنند.

مرجع providerAuthChoices

هر ورودی providerAuthChoices یک گزینهٔ onboarding یا احراز هویت را توصیف می‌کند. OpenClaw این را پیش از بارگذاری زمان اجرای ارائه‌دهنده می‌خواند. فهرست‌های راه‌اندازی ارائه‌دهنده از این گزینه‌های manifest، گزینه‌های راه‌اندازی مشتق‌شده از descriptor، و فرادادهٔ کاتالوگ نصب بدون بارگذاری زمان اجرای ارائه‌دهنده استفاده می‌کنند.

مرجع commandAliases

از commandAliases زمانی استفاده کنید که یک Plugin مالک نام فرمان runtime است که کاربران ممکن است به‌اشتباه آن را در plugins.allow قرار دهند یا تلاش کنند آن را به‌عنوان فرمان ریشه CLI اجرا کنند. OpenClaw از این metadata برای diagnostics بدون import کردن کد runtime مربوط به Plugin استفاده می‌کند.

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

مرجع activation

از activation زمانی استفاده کنید که Plugin بتواند به‌صورت کم‌هزینه اعلام کند کدام رویدادهای control-plane باید آن را در طرح activation/load وارد کنند.

این بلوک metadata مربوط به planner است، نه یک API چرخه‌عمر. رفتار runtime را ثبت نمی‌کند، جایگزین register(...) نمی‌شود، و وعده نمی‌دهد که کد Plugin از قبل اجرا شده است. planner فعال‌سازی از این فیلدها برای محدود کردن Pluginهای نامزد پیش از بازگشت به metadata مالکیت موجود در manifest مانند providers، channels، commandAliases، setup.providers، contracts.tools و hooks استفاده می‌کند.

باریک‌ترین metadataای را ترجیح دهید که از قبل مالکیت را توصیف می‌کند. زمانی از providers، channels، commandAliases، توصیفگرهای setup، یا contracts استفاده کنید که آن فیلدها رابطه را بیان می‌کنند. از activation برای راهنمایی‌های اضافی planner استفاده کنید که با آن فیلدهای مالکیت قابل نمایش نیستند. برای aliasهای runtime مربوط به CLI مانند claude-cli، codex-cli، یا google-gemini-cli از cliBackends در سطح بالا استفاده کنید؛ activation.onAgentHarnesses فقط برای شناسه‌های agent harness توکار است که از قبل فیلد مالکیت ندارند.

این بلوک فقط metadata است. رفتار runtime را ثبت نمی‌کند، و جایگزین register(...)، setupEntry، یا entrypointهای runtime/Plugin دیگر نمی‌شود. مصرف‌کنندگان فعلی از آن به‌عنوان راهنمای محدودسازی پیش از بارگذاری گسترده‌تر Plugin استفاده می‌کنند، بنابراین نبود metadata فعال‌سازی غیر-startup معمولاً فقط هزینه عملکردی دارد؛ تا زمانی که fallbackهای مالکیت manifest هنوز وجود دارند، نباید درستی را تغییر دهد.

هر Plugin باید activation.onStartup را آگاهانه تنظیم کند. فقط زمانی آن را روی true بگذارید که Plugin باید هنگام startup مربوط به Gateway اجرا شود. زمانی آن را روی false بگذارید که Plugin در startup غیرفعال است و باید فقط از طریق triggerهای باریک‌تر load شود. حذف onStartup دیگر Plugin را به‌صورت ضمنی در startup بارگذاری نمی‌کند؛ برای startup، channel، config، agent-harness، memory، یا triggerهای فعال‌سازی باریک‌تر دیگر از metadata فعال‌سازی صریح استفاده کنید.

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

مصرف‌کنندگان live فعلی:

• برنامه‌ریزی startup مربوط به Gateway از activation.onStartup برای import صریح هنگام startup استفاده می‌کند
• برنامه‌ریزی CLI که با command trigger می‌شود به commandAliases[].cliCommand یا commandAliases[].name قدیمی fallback می‌کند
• برنامه‌ریزی startup مربوط به agent-runtime از activation.onAgentHarnesses برای harnessهای توکار و از cliBackends[] در سطح بالا برای aliasهای runtime مربوط به CLI استفاده می‌کند
• برنامه‌ریزی setup/channel که با channel trigger می‌شود، زمانی که metadata فعال‌سازی صریح channel وجود ندارد، به مالکیت channels[] قدیمی fallback می‌کند
• برنامه‌ریزی Plugin در startup از activation.onConfigPaths برای سطوح config ریشه غیر-channel مانند بلوک browser مربوط به Plugin مرورگر bundled استفاده می‌کند
• برنامه‌ریزی setup/runtime که با provider trigger می‌شود، زمانی که metadata فعال‌سازی صریح provider وجود ندارد، به مالکیت providers[] قدیمی و cliBackends[] در سطح بالا fallback می‌کند

diagnostics مربوط به planner می‌تواند راهنمایی‌های فعال‌سازی صریح را از fallback مالکیت manifest تمایز دهد. برای مثال، activation-command-hint یعنی activation.onCommands منطبق شده است، در حالی که manifest-command-alias یعنی planner به‌جای آن از مالکیت commandAliases استفاده کرده است. این برچسب‌های دلیل برای diagnostics و testهای host هستند؛ نویسندگان Plugin باید همچنان metadataای را اعلام کنند که مالکیت را به بهترین شکل توصیف می‌کند.

مرجع qaRunners

از qaRunners زمانی استفاده کنید که یک Plugin یک یا چند transport runner زیر ریشه مشترک openclaw qa اضافه می‌کند. این metadata را کم‌هزینه و static نگه دارید؛ runtime مربوط به Plugin هنوز مالک ثبت واقعی CLI از طریق یک سطح سبک runtime-api.ts است که qaRunnerCliRegistrations را export می‌کند.

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

مرجع setup

از setup زمانی استفاده کنید که سطوح setup و onboarding پیش از load شدن runtime به metadata کم‌هزینه و متعلق به Plugin نیاز دارند.

{  "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 در سطح بالا معتبر می‌ماند و همچنان backendهای inference مربوط به CLI را توصیف می‌کند. setup.cliBackends سطح توصیفگر اختصاصی setup برای جریان‌های control-plane/setup است که باید فقط metadata باقی بمانند.

وقتی وجود داشته باشند، setup.providers و setup.cliBackends سطح lookup ترجیحی descriptor-first برای کشف setup هستند. اگر descriptor فقط Plugin نامزد را محدود می‌کند و setup هنوز به hookهای runtime غنی‌تر در زمان setup نیاز دارد، requiresRuntime: true را تنظیم کنید و setup-api را به‌عنوان مسیر اجرای fallback حفظ کنید.

OpenClaw همچنین setup.providers[].envVars را در lookupهای عمومی auth مربوط به provider و env-var وارد می‌کند. providerAuthEnvVars در طول پنجره deprecation همچنان از طریق یک compatibility adapter پشتیبانی می‌شود، اما Pluginهای غیر-bundled که هنوز از آن استفاده می‌کنند یک diagnostic مربوط به manifest دریافت می‌کنند. Pluginهای جدید باید metadata مربوط به env برای setup/status را در setup.providers[].envVars قرار دهند.

OpenClaw همچنین می‌تواند انتخاب‌های setup ساده را از setup.providers[].authMethods استنتاج کند، زمانی که entry مربوط به setup در دسترس نیست، یا زمانی که setup.requiresRuntime: false اعلام می‌کند runtime مربوط به setup لازم نیست. entryهای صریح providerAuthChoices برای برچسب‌های سفارشی، flagهای CLI، دامنه onboarding، و metadata دستیار همچنان ترجیح داده می‌شوند.

requiresRuntime: false را فقط زمانی تنظیم کنید که آن descriptorها برای سطح setup کافی باشند. OpenClaw مقدار صریح false را به‌عنوان قرارداد descriptor-only در نظر می‌گیرد و برای lookup مربوط به setup، setup-api یا openclaw.setupEntry را اجرا نخواهد کرد. اگر یک Plugin descriptor-only همچنان یکی از آن entryهای runtime مربوط به setup را ارائه کند، OpenClaw یک diagnostic افزایشی گزارش می‌دهد و همچنان آن را نادیده می‌گیرد. حذف requiresRuntime رفتار fallback قدیمی را حفظ می‌کند تا Pluginهای موجود که descriptorها را بدون flag اضافه کرده‌اند خراب نشوند.

از آنجا که lookup مربوط به setup می‌تواند کد setup-api متعلق به Plugin را اجرا کند، مقدارهای normalized setup.providers[].id و setup.cliBackends[] باید در میان Pluginهای کشف‌شده یکتا بمانند. مالکیت مبهم به‌جای انتخاب یک برنده از ترتیب کشف، به‌صورت fail closed عمل می‌کند.

وقتی runtime مربوط به setup اجرا می‌شود، diagnostics رجیستری setup در صورتی descriptor drift را گزارش می‌کند که setup-api یک provider یا backend مربوط به CLI را ثبت کند که descriptorهای manifest اعلام نکرده‌اند، یا اگر یک descriptor ثبت runtime منطبق نداشته باشد. این diagnostics افزایشی هستند و Pluginهای قدیمی را رد نمی‌کنند.

مرجع setup.providers

authEvidence برای نشانگرهای اعتبارنامهٔ محلیِ تحت مالکیت ارائه‌دهنده است که می‌توانند بدون بارگذاری کد runtime راستی‌آزمایی شوند. این بررسی‌ها باید ارزان و محلی بمانند: بدون فراخوانی شبکه، بدون خواندن keychain یا secret-manager، بدون فرمان‌های shell، و بدون کاوش API ارائه‌دهنده.

ورودی‌های شواهد پشتیبانی‌شده:

فیلدهای setup

مرجع uiHints

uiHints نگاشتی از نام فیلدهای پیکربندی به راهنمایی‌های کوچک رندر است.

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

هر راهنمای فیلد می‌تواند شامل موارد زیر باشد:

مرجع contracts

از contracts فقط برای فرادادهٔ ایستای مالکیت قابلیت استفاده کنید که OpenClaw می‌تواند بدون import کردن runtime plugin آن را بخواند.

{  "contracts": {    "agentToolResultMiddleware": ["pi", "codex"],    "externalAuthProviders": ["acme-ai"],    "speechProviders": ["openai"],    "realtimeTranscriptionProviders": ["openai"],    "realtimeVoiceProviders": ["openai"],    "memoryEmbeddingProviders": ["local"],    "mediaUnderstandingProviders": ["openai", "openai-codex"],    "imageGenerationProviders": ["openai"],    "videoGenerationProviders": ["qwen"],    "webFetchProviders": ["firecrawl"],    "webSearchProviders": ["gemini"],    "migrationProviders": ["hermes"],    "tools": ["firecrawl_search", "firecrawl_scrape"]  }}

هر فهرست اختیاری است:

contracts.embeddedExtensionFactories برای factoryهای اکستنشنِ فقط app-server و همراه Codex نگه داشته شده است. تبدیل‌های همراهِ نتیجهٔ ابزار باید در عوض contracts.agentToolResultMiddleware را اعلام کنند و با api.registerAgentToolResultMiddleware(...) ثبت شوند. pluginهای خارجی نمی‌توانند middleware نتیجهٔ ابزار را ثبت کنند، زیرا این seam می‌تواند خروجی ابزار با اعتماد بالا را پیش از آنکه مدل آن را ببیند بازنویسی کند.

ثبت‌های runtime api.registerTool(...) باید با contracts.tools مطابق باشند. کشف ابزار از این فهرست استفاده می‌کند تا فقط runtimeهای pluginهایی را بارگذاری کند که می‌توانند مالک ابزارهای درخواست‌شده باشند.

pluginهای ارائه‌دهنده‌ای که resolveExternalAuthProfiles را پیاده‌سازی می‌کنند باید contracts.externalAuthProviders را اعلام کنند. pluginهای بدون این اعلامیه هنوز از مسیر fallback سازگاری منسوخ‌شده اجرا می‌شوند، اما آن fallback کندتر است و پس از بازهٔ مهاجرت حذف خواهد شد.

ارائه‌دهنده‌های embedding حافظهٔ همراه باید contracts.memoryEmbeddingProviders را برای هر شناسهٔ adapter که عرضه می‌کنند اعلام کنند، از جمله adapterهای داخلی مانند local. مسیرهای CLI مستقل از این قرارداد manifest استفاده می‌کنند تا پیش از آنکه runtime کامل Gateway ارائه‌دهنده‌ها را ثبت کرده باشد، فقط plugin مالک را بارگذاری کنند.

مرجع mediaUnderstandingProviderMetadata

از mediaUnderstandingProviderMetadata زمانی استفاده کنید که یک ارائه‌دهندهٔ فهم رسانه مدل‌های پیش‌فرض، اولویت fallback احراز هویت خودکار، یا پشتیبانی بومی از سند داشته باشد که کمک‌کننده‌های generic هسته پیش از بارگذاری runtime به آن نیاز دارند. کلیدها باید همچنین در contracts.mediaUnderstandingProviders اعلام شده باشند.

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

هر ورودی ارائه‌دهنده می‌تواند شامل موارد زیر باشد:

مرجع channelConfigs

از channelConfigs زمانی استفاده کنید که یک plugin کانال پیش از بارگذاری runtime به فرادادهٔ پیکربندی ارزان نیاز داشته باشد. کشف فقط‌خواندنی setup/status کانال می‌تواند از این فراداده مستقیما برای کانال‌های خارجی پیکربندی‌شده استفاده کند، وقتی هیچ ورودی setup در دسترس نیست، یا وقتی setup.requiresRuntime: false اعلام می‌کند runtime setup غیرضروری است.

channelConfigs فرادادهٔ manifest plugin است، نه یک بخش پیکربندی سطح‌بالای جدید برای کاربر. کاربران همچنان instanceهای کانال را زیر channels.<channel-id> پیکربندی می‌کنند. OpenClaw فرادادهٔ manifest را می‌خواند تا پیش از اجرای کد runtime plugin تصمیم بگیرد کدام plugin مالک آن کانال پیکربندی‌شده است.

برای یک plugin کانال، configSchema و channelConfigs مسیرهای متفاوتی را توصیف می‌کنند:

• configSchema اعتبارسنجی plugins.entries.<plugin-id>.config را انجام می‌دهد
• channelConfigs.<channel-id>.schema اعتبارسنجی channels.<channel-id> را انجام می‌دهد

pluginهای غیرهمراهی که channels[] را اعلام می‌کنند باید ورودی‌های منطبق channelConfigs را نیز اعلام کنند. بدون آن‌ها، OpenClaw همچنان می‌تواند plugin را بارگذاری کند، اما سطوح schema پیکربندی مسیر سرد، setup، و Control UI نمی‌توانند شکل گزینه‌های تحت مالکیت کانال را تا زمان اجرای runtime plugin بدانند.

channelConfigs.<channel-id>.commands.nativeCommandsAutoEnabled و nativeSkillsAutoEnabled می‌توانند پیش‌فرض‌های ایستای auto را برای بررسی‌های پیکربندی command که پیش از بارگذاری runtime کانال اجرا می‌شوند اعلام کنند. کانال‌های همراه نیز می‌توانند همان پیش‌فرض‌ها را از طریق package.json#openclaw.channel.commands در کنار فرادادهٔ کاتالوگ کانالِ تحت مالکیت package خود منتشر کنند.

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

هر ورودی کانال می‌تواند شامل موارد زیر باشد:

جایگزینی یک پلاگین کانال دیگر

وقتی پلاگین شما مالک ترجیحی برای شناسه کانالی است که پلاگین دیگری نیز می‌تواند ارائه کند، از preferOver استفاده کنید. موارد رایج شامل شناسه پلاگین تغییرنام‌یافته، پلاگین مستقلی که جایگزین یک پلاگین بسته‌بندی‌شده می‌شود، یا فورک نگهداری‌شده‌ای است که برای سازگاری پیکربندی همان شناسه کانال را نگه می‌دارد.

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

وقتی channels.chat پیکربندی شده باشد، OpenClaw هم شناسه کانال و هم شناسه پلاگین ترجیحی را در نظر می‌گیرد. اگر پلاگین کم‌اولویت‌تر فقط به این دلیل انتخاب شده باشد که بسته‌بندی‌شده است یا به‌صورت پیش‌فرض فعال شده، OpenClaw آن را در پیکربندی مؤثر زمان اجرا غیرفعال می‌کند تا یک پلاگین مالک کانال و ابزارهای آن باشد. انتخاب صریح کاربر همچنان برنده است: اگر کاربر هر دو پلاگین را صراحتاً فعال کند، OpenClaw آن انتخاب را حفظ می‌کند و به‌جای تغییر بی‌صدای مجموعه پلاگین‌های درخواستی، عیب‌یابی‌های کانال/ابزار تکراری را گزارش می‌دهد.

preferOver را فقط به شناسه‌های پلاگینی محدود کنید که واقعاً می‌توانند همان کانال را ارائه کنند. این یک فیلد اولویت عمومی نیست و کلیدهای پیکربندی کاربر را تغییرنام نمی‌دهد.

مرجع modelSupport

وقتی OpenClaw باید پیش از بارگذاری زمان اجرای پلاگین، پلاگین ارائه‌دهنده شما را از شناسه‌های کوتاه مدل مانند gpt-5.5 یا claude-sonnet-4.6 استنتاج کند، از modelSupport استفاده کنید.

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

OpenClaw این تقدم را اعمال می‌کند:

• ارجاع‌های صریح provider/model از فراداده مانیفست providers مالک استفاده می‌کنند
• modelPatterns بر modelPrefixes مقدم است
• اگر یک پلاگین غیربسته‌بندی‌شده و یک پلاگین بسته‌بندی‌شده هر دو منطبق باشند، پلاگین غیربسته‌بندی‌شده برنده می‌شود
• ابهام باقی‌مانده تا زمانی که کاربر یا پیکربندی ارائه‌دهنده‌ای را مشخص کند نادیده گرفته می‌شود

فیلدها:

مرجع modelCatalog

وقتی OpenClaw باید پیش از بارگذاری زمان اجرای پلاگین، فراداده مدل ارائه‌دهنده را بداند، از modelCatalog استفاده کنید. این منبع تحت مالکیت مانیفست برای ردیف‌های ثابت کاتالوگ، نام‌های مستعار ارائه‌دهنده، قواعد سرکوب، و حالت کشف است. تازه‌سازی زمان اجرا همچنان به کد زمان اجرای ارائه‌دهنده تعلق دارد، اما مانیفست به هسته می‌گوید چه زمانی زمان اجرا لازم است.

{  "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 در جست‌وجوی مالکیت ارائه‌دهنده برای برنامه‌ریزی کاتالوگ مدل مشارکت می‌کند. هدف‌های نام مستعار باید ارائه‌دهندگان سطح بالایی باشند که مالکشان همان پلاگین است. وقتی یک فهرست فیلترشده بر اساس ارائه‌دهنده از نام مستعار استفاده می‌کند، OpenClaw می‌تواند مانیفست مالک را بخواند و بدون بارگذاری زمان اجرای ارائه‌دهنده، بازنویسی‌های API/نشانی پایه نام مستعار را اعمال کند. نام‌های مستعار فهرست‌های کاتالوگ بدون فیلتر را گسترش نمی‌دهند؛ فهرست‌های گسترده فقط ردیف‌های ارائه‌دهنده canonical مالک را منتشر می‌کنند.

suppressions جایگزین hook قدیمی suppressBuiltInModel زمان اجرای ارائه‌دهنده می‌شود. ورودی‌های سرکوب فقط زمانی رعایت می‌شوند که ارائه‌دهنده مالکیتش با پلاگین باشد یا به‌عنوان یک کلید modelCatalog.aliases اعلام شده باشد که به یک ارائه‌دهنده تحت مالکیت اشاره می‌کند. hookهای سرکوب زمان اجرا دیگر هنگام حل مدل فراخوانی نمی‌شوند.

فیلدهای ارائه‌دهنده:

فیلدهای مدل:

فیلدهای سرکوب:

داده‌های فقط زمان اجرا را در modelCatalog قرار ندهید. فقط زمانی از static استفاده کنید که ردیف‌های مانیفست برای سطح‌های فهرست و انتخاب‌گر فیلترشده بر اساس ارائه‌دهنده به اندازه‌ی کافی کامل باشند تا بتوانند از کشف registry/زمان اجرا صرف‌نظر کنند. زمانی از refreshable استفاده کنید که ردیف‌های مانیفست دانه‌ها یا تکمیل‌کننده‌های قابل‌فهرست‌سازی مفیدی باشند، اما refresh/cache بتواند بعدا ردیف‌های بیشتری اضافه کند؛ ردیف‌های refreshable به‌تنهایی مرجع قطعی نیستند. زمانی از runtime استفاده کنید که OpenClaw برای دانستن فهرست باید زمان اجرای ارائه‌دهنده را بارگذاری کند.

مرجع modelIdNormalization

از modelIdNormalization برای پاک‌سازی ارزان model-id متعلق به ارائه‌دهنده استفاده کنید که باید پیش از بارگذاری زمان اجرای ارائه‌دهنده انجام شود. این کار aliasهایی مانند نام‌های کوتاه مدل، شناسه‌های قدیمی محلیِ ارائه‌دهنده، و قواعد پیشوند proxy را به‌جای جدول‌های انتخاب مدل در core، در مانیفست Plugin مالک نگه می‌دارد.

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

فیلدهای ارائه‌دهنده:

مرجع providerEndpoints

از providerEndpoints برای طبقه‌بندی endpoint استفاده کنید که سیاست درخواست عمومی باید پیش از بارگذاری زمان اجرای ارائه‌دهنده بداند. core همچنان مالک معنای هر endpointClass است؛ مانیفست‌های Plugin مالک فراداده‌ی میزبان و URL پایه هستند.

فیلدهای endpoint:

مرجع providerRequest

از providerRequest برای فراداده‌ی ارزان سازگاری درخواست استفاده کنید که سیاست درخواست عمومی بدون بارگذاری زمان اجرای ارائه‌دهنده نیاز دارد. بازنویسی payload وابسته به رفتار را در hookهای زمان اجرای ارائه‌دهنده یا helperهای مشترک خانواده‌ی ارائه‌دهنده نگه دارید.

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

فیلدهای ارائه‌دهنده:

مرجع modelPricing

زمانی از modelPricing استفاده کنید که یک ارائه‌دهنده پیش از بارگذاری زمان اجرا به رفتار قیمت‌گذاری control-plane نیاز دارد. کش قیمت‌گذاری Gateway این فراداده را بدون import کردن کد زمان اجرای ارائه‌دهنده می‌خواند.

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

فیلدهای ارائه‌دهنده:

فیلدهای منبع:

نمایه‌ی ارائه‌دهندگان OpenClaw

نمایه‌ی ارائه‌دهندگان OpenClaw فراداده‌ی preview متعلق به OpenClaw برای ارائه‌دهندگانی است که Pluginهایشان ممکن است هنوز نصب نشده باشند. این بخشی از مانیفست Plugin نیست. مانیفست‌های Plugin همچنان مرجع Plugin نصب‌شده هستند. نمایه‌ی ارائه‌دهندگان قرارداد fallback داخلی است که سطح‌های آینده‌ی ارائه‌دهنده‌ی قابل‌نصب و انتخاب‌گر مدل پیش از نصب وقتی Plugin ارائه‌دهنده نصب نشده باشد مصرف خواهند کرد.

ترتیب مرجعیت کاتالوگ:

1. پیکربندی کاربر.
2. modelCatalog مانیفست Plugin نصب‌شده.
3. کش کاتالوگ مدل از refresh صریح.
4. ردیف‌های preview نمایه‌ی ارائه‌دهندگان OpenClaw.

نمایه‌ی ارائه‌دهندگان نباید شامل secretها، وضعیت فعال‌بودن، hookهای زمان اجرا، یا داده‌ی زنده‌ی مدلِ ویژه‌ی حساب باشد. کاتالوگ‌های preview آن از همان شکل ردیف ارائه‌دهنده‌ی modelCatalog مانند مانیفست‌های Plugin استفاده می‌کنند، اما باید به فراداده‌ی نمایشی پایدار محدود بمانند مگر اینکه فیلدهای runtime adapter مانند api، baseUrl، قیمت‌گذاری، یا flagهای سازگاری عمدا با مانیفست Plugin نصب‌شده هم‌راستا نگه داشته شوند. ارائه‌دهندگانی با کشف زنده‌ی /models باید به‌جای اینکه فهرست‌کردن معمول یا onboarding APIهای ارائه‌دهنده را فراخوانی کند، ردیف‌های refreshشده را از مسیر صریح کش کاتالوگ مدل بنویسند.

ورودی‌های نمایه‌ی ارائه‌دهندگان همچنین می‌توانند فراداده‌ی Plugin قابل‌نصب را برای ارائه‌دهندگانی حمل کنند که Plugin آن‌ها از core خارج شده یا در غیر این صورت هنوز نصب نشده است. این فراداده از الگوی کاتالوگ channel پیروی می‌کند: نام package، spec نصب npm، integrity مورد انتظار، و برچسب‌های ارزان انتخاب auth برای نمایش یک گزینه‌ی setup قابل‌نصب کافی هستند. پس از نصب Plugin، مانیفست آن برنده می‌شود و ورودی نمایه‌ی ارائه‌دهندگان برای آن ارائه‌دهنده نادیده گرفته می‌شود.

کلیدهای capability سطح بالای قدیمی منسوخ شده‌اند. از openclaw doctor --fix برای انتقال speechProviders، realtimeTranscriptionProviders، realtimeVoiceProviders، mediaUnderstandingProviders، imageGenerationProviders، videoGenerationProviders، webFetchProviders، و webSearchProviders به زیر contracts استفاده کنید؛ بارگذاری عادی مانیفست دیگر آن فیلدهای سطح بالا را به‌عنوان مالکیت capability در نظر نمی‌گیرد.

مانیفست در برابر package.json

این دو فایل وظایف متفاوتی دارند:

اگر مطمئن نیستید یک قطعه فراداده کجا باید قرار بگیرد، از این قاعده استفاده کنید:

• اگر OpenClaw باید آن را پیش از بارگذاری کد Plugin بداند، آن را در openclaw.plugin.json قرار دهید
• اگر درباره‌ی packaging، فایل‌های entry، یا رفتار نصب npm است، آن را در package.json قرار دهید

فیلدهای package.json که بر کشف اثر می‌گذارند

بعضی فراداده‌های پیش از زمان اجرای Plugin عمدا به‌جای openclaw.plugin.json در بلوک openclaw در package.json قرار می‌گیرند. openclaw.bundle و openclaw.bundle.json قراردادهای Plugin در OpenClaw نیستند؛ Pluginهای native باید از openclaw.plugin.json به‌همراه فیلدهای پشتیبانی‌شده‌ی package.json#openclaw زیر استفاده کنند.

نمونه‌های مهم:

فرادادهٔ manifest تعیین می‌کند کدام انتخاب‌های provider/کانال/راه‌اندازی پیش از بارگذاری runtime در onboarding ظاهر شوند. package.json#openclaw.install به onboarding می‌گوید وقتی کاربر یکی از آن انتخاب‌ها را برمی‌گزیند، چگونه آن Plugin را دریافت یا فعال کند. راهنمایی‌های نصب را به openclaw.plugin.json منتقل نکنید.

openclaw.install.minHostVersion هنگام نصب و بارگذاری registry manifest برای منابع Plugin غیر بسته‌بندی‌شده اعمال می‌شود. مقادیر نامعتبر رد می‌شوند؛ مقادیر جدیدتر اما معتبر، Pluginهای خارجی را روی میزبان‌های قدیمی‌تر نادیده می‌گیرند. Pluginهای منبع بسته‌بندی‌شده فرض می‌شوند که هم‌نسخه با checkout میزبان هستند.

فرادادهٔ رسمی install-on-demand باید وقتی Plugin روی ClawHub منتشر شده است از clawhubSpec استفاده کند؛ onboarding آن را به‌عنوان منبع راه‌دور ترجیحی در نظر می‌گیرد و پس از نصب، واقعیت‌های artifact مربوط به ClawHub را ثبت می‌کند. npmSpec همچنان fallback سازگاری برای بسته‌هایی است که هنوز به ClawHub منتقل نشده‌اند.

پین‌کردن دقیق نسخهٔ npm از قبل در npmSpec قرار دارد، برای مثال "npmSpec": "@wecom/wecom-openclaw-plugin@1.2.3". مدخل‌های رسمی کاتالوگ خارجی باید specهای دقیق را با expectedIntegrity جفت کنند تا اگر artifact دریافت‌شدهٔ npm دیگر با انتشار پین‌شده مطابقت نداشت، جریان‌های به‌روزرسانی به‌صورت بسته شکست بخورند. onboarding تعاملی همچنان برای سازگاری، specهای npm از registry مورد اعتماد، از جمله نام‌های خام بسته و dist-tagها، را ارائه می‌دهد. عیب‌یابی‌های کاتالوگ می‌توانند منابع دقیق، شناور، پین‌شده با integrity، فاقد integrity، دارای عدم تطابق نام بسته، و default-choice نامعتبر را از هم تشخیص دهند. همچنین وقتی expectedIntegrity وجود دارد اما هیچ منبع npm معتبری که بتواند آن را پین کند وجود ندارد هشدار می‌دهند. وقتی expectedIntegrity وجود دارد، جریان‌های نصب/به‌روزرسانی آن را اعمال می‌کنند؛ وقتی حذف شده باشد، resolution رجیستری بدون پین integrity ثبت می‌شود.

Pluginهای کانال باید وقتی اسکن‌های وضعیت، فهرست کانال، یا SecretRef باید حساب‌های پیکربندی‌شده را بدون بارگذاری runtime کامل شناسایی کنند، openclaw.setupEntry ارائه دهند. نقطهٔ ورود راه‌اندازی باید فرادادهٔ کانال به‌همراه پیکربندی، و adapterهای وضعیت و secrets امن برای راه‌اندازی را ارائه کند؛ کلاینت‌های شبکه، شنونده‌های Gateway، و runtimeهای transport را در نقطهٔ ورود اصلی extension نگه دارید.

فیلدهای نقطهٔ ورود runtime، بررسی‌های مرز بسته برای فیلدهای نقطهٔ ورود منبع را override نمی‌کنند. برای مثال، openclaw.runtimeExtensions نمی‌تواند یک مسیر openclaw.extensions خارج‌شونده را قابل بارگذاری کند.

openclaw.install.allowInvalidConfigRecovery عمدا محدود است. این پیکربندی‌های خراب دلخواه را قابل نصب نمی‌کند. امروزه فقط به جریان‌های نصب اجازه می‌دهد از شکست‌های مشخص و stale ارتقای Plugin بسته‌بندی‌شده بازیابی شوند، مانند یک مسیر گم‌شدهٔ Plugin بسته‌بندی‌شده یا یک مدخل stale از channels.<id> برای همان Plugin بسته‌بندی‌شده. خطاهای پیکربندی نامرتبط همچنان نصب را مسدود می‌کنند و operatorها را به openclaw doctor --fix می‌فرستند.

openclaw.channel.persistedAuthState فرادادهٔ بسته برای یک module بررسی‌کنندهٔ کوچک است:

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

وقتی جریان‌های راه‌اندازی، doctor، وضعیت، یا حضور فقط‌خواندنی پیش از بارگذاری Plugin کامل کانال به یک probe احراز هویت ارزان yes/no نیاز دارند، از آن استفاده کنید. وضعیت احراز هویت پایدار وضعیت کانال پیکربندی‌شده نیست: از این فراداده برای فعال‌سازی خودکار Pluginها، تعمیر وابستگی‌های runtime، یا تصمیم‌گیری دربارهٔ اینکه آیا runtime کانال باید بارگذاری شود استفاده نکنید. export هدف باید یک تابع کوچک باشد که فقط وضعیت پایدار را می‌خواند؛ آن را از طریق barrel کامل runtime کانال عبور ندهید.

openclaw.channel.configuredState برای بررسی‌های ارزان وضعیت پیکربندی‌شدهٔ فقط-env از همان شکل پیروی می‌کند:

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

وقتی یک کانال می‌تواند وضعیت پیکربندی‌شده را از env یا ورودی‌های کوچک غیر-runtime دیگر پاسخ دهد، از آن استفاده کنید. اگر بررسی به resolution کامل پیکربندی یا runtime واقعی کانال نیاز دارد، آن منطق را به‌جای آن در hook مربوط به config.hasConfiguredState در Plugin نگه دارید.

تقدم کشف (idهای تکراری Plugin)

OpenClaw، Pluginها را از چند ریشه کشف می‌کند (بسته‌بندی‌شده، نصب global، workspace، مسیرهای صریح انتخاب‌شده در پیکربندی). اگر دو کشف id یکسان داشته باشند، فقط manifest با بالاترین تقدم نگه داشته می‌شود؛ تکراری‌های با تقدم پایین‌تر به‌جای بارگذاری در کنار آن، کنار گذاشته می‌شوند.

تقدم، از بیشترین به کمترین:

1. انتخاب‌شده در پیکربندی — مسیری که به‌صراحت در plugins.entries.<id> پین شده است
2. بسته‌بندی‌شده — Pluginهایی که همراه OpenClaw ارائه می‌شوند
3. نصب global — Pluginهایی که در ریشهٔ global Plugin مربوط به OpenClaw نصب شده‌اند
4. Workspace — Pluginهایی که نسبت به workspace فعلی کشف می‌شوند

پیامدها:

• یک کپی fork شده یا stale از یک Plugin بسته‌بندی‌شده که در workspace قرار دارد، build بسته‌بندی‌شده را shadow نمی‌کند.
• برای override واقعی یک Plugin بسته‌بندی‌شده با نمونهٔ local، آن را از طریق plugins.entries.<id> پین کنید تا با تقدم برنده شود، نه اینکه به کشف workspace تکیه کنید.
• کنارگذاشتن تکراری‌ها log می‌شود تا Doctor و عیب‌یابی‌های startup بتوانند به کپی کنارگذاشته‌شده اشاره کنند.
• overrideهای تکراریِ انتخاب‌شده در پیکربندی در عیب‌یابی‌ها به‌عنوان overrideهای صریح بیان می‌شوند، اما همچنان هشدار می‌دهند تا forkهای stale و shadowهای تصادفی قابل مشاهده بمانند.

الزامات JSON Schema

• هر Plugin باید یک JSON Schema ارائه کند، حتی اگر هیچ پیکربندی‌ای نمی‌پذیرد.
• یک schema خالی قابل قبول است (برای مثال، { "type": "object", "additionalProperties": false }).
• schemaها هنگام خواندن/نوشتن پیکربندی اعتبارسنجی می‌شوند، نه در runtime.
• هنگام گسترش یا fork کردن یک Plugin بسته‌بندی‌شده با کلیدهای پیکربندی جدید، هم‌زمان configSchema در openclaw.plugin.json همان Plugin را به‌روزرسانی کنید. schemaهای Plugin بسته‌بندی‌شده سخت‌گیرانه‌اند، بنابراین افزودن plugins.entries.<id>.config.myNewKey در پیکربندی کاربر بدون افزودن myNewKey به configSchema.properties پیش از بارگذاری runtime Plugin رد خواهد شد.

نمونهٔ گسترش schema:

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

رفتار اعتبارسنجی

• کلیدهای ناشناختهٔ channels.* خطا هستند، مگر اینکه id کانال توسط manifest یک Plugin اعلام شده باشد.
• plugins.entries.<id>، plugins.allow، plugins.deny، و plugins.slots.* باید به idهای Plugin قابل کشف اشاره کنند. idهای ناشناخته خطا هستند.
• اگر Plugin نصب شده باشد اما manifest یا schema خراب یا گم‌شده داشته باشد، اعتبارسنجی شکست می‌خورد و Doctor خطای Plugin را گزارش می‌کند.
• اگر پیکربندی Plugin وجود داشته باشد اما Plugin غیرفعال باشد، پیکربندی نگه داشته می‌شود و یک هشدار در Doctor و logها نمایش داده می‌شود.

برای schema کامل plugins.*، مرجع پیکربندی را ببینید.

یادداشت‌ها

• manifest برای Pluginهای بومی OpenClaw الزامی است، از جمله بارگذاری‌ها از فایل‌سیستم محلی. Runtime همچنان ماژول Plugin را جداگانه بارگذاری می‌کند؛ manifest فقط برای کشف + اعتبارسنجی است.
• manifestهای بومی با JSON5 تجزیه می‌شوند، بنابراین تا زمانی که مقدار نهایی همچنان یک شیء باشد، commentها، ویرگول‌های انتهایی، و کلیدهای بدون کوتیشن پذیرفته می‌شوند.
• manifest loader فقط فیلدهای مستندسازی‌شده‌ی manifest را می‌خواند. از کلیدهای سفارشی در سطح بالا پرهیز کنید.
• وقتی یک Plugin به channels، providers، cliBackends، و skills نیاز ندارد، همه‌ی آن‌ها می‌توانند حذف شوند.
• providerCatalogEntry باید سبک بماند و نباید کد گسترده‌ی Runtime را import کند؛ از آن برای فراداده‌ی ثابت کاتالوگ provider یا توصیف‌گرهای محدود کشف استفاده کنید، نه اجرای زمان درخواست. providerDiscoveryEntry املای قدیمی است و همچنان برای Pluginهای موجود کار می‌کند.
• نوع‌های انحصاری Plugin از طریق plugins.slots.* انتخاب می‌شوند: kind: "memory" از طریق plugins.slots.memory، و kind: "context-engine" از طریق plugins.slots.contextEngine (پیش‌فرض legacy).
• نوع انحصاری Plugin را در این manifest اعلام کنید. OpenClawPluginDefinition.kind در مدخل Runtime منسوخ شده و فقط به‌عنوان fallback سازگاری برای Pluginهای قدیمی‌تر باقی مانده است.
• فراداده‌ی env-var (setup.providers[].envVars، providerAuthEnvVars منسوخ‌شده، و channelEnvVars) فقط اعلانی است. وضعیت، audit، اعتبارسنجی تحویل Cron، و سایر سطح‌های فقط‌خواندنی همچنان پیش از اینکه یک env var را پیکربندی‌شده در نظر بگیرند، سیاست اعتماد Plugin و فعال‌سازی مؤثر را اعمال می‌کنند.
• برای فراداده‌ی wizard در Runtime که به کد provider نیاز دارد، قلاب‌های Runtime provider را ببینید.
• اگر Plugin شما به native moduleها وابسته است، مراحل build و هرگونه نیازمندی allowlist مربوط به package manager را مستند کنید (برای مثال، pnpm allow-build-scripts + pnpm rebuild <package>).

مرتبط