Skip to main content
OpenClaw पुराने plugin अनुबंधों को हटाने से पहले नामित संगतता एडाप्टरों के माध्यम से जोड़े रखता है। इससे SDK, मैनिफ़ेस्ट, सेटअप, कॉन्फ़िगरेशन और एजेंट रनटाइम अनुबंधों के विकसित होने के दौरान मौजूदा बंडल किए गए और बाहरी plugins सुरक्षित रहते हैं।

संगतता रजिस्ट्री

Plugin संगतता अनुबंधों को कोर रजिस्ट्री में src/plugins/compat/registry.ts पर ट्रैक किया जाता है। प्रत्येक रिकॉर्ड में ये होते हैं:
  • एक स्थिर संगतता कोड
  • स्थिति: active, deprecated, removal-pending, या removed
  • स्वामी: sdk, config, setup, channel, provider, plugin-execution, agent-runtime, या core
  • लागू होने पर प्रस्तुत किए जाने और अप्रचलन की तिथियाँ
  • स्वामी अनुरक्षक द्वारा स्वीकृति दिए जाने के बाद हटाने की सटीक तिथि; छोड़ा गया removeAfter किसी अप्रचलित सतह को हटाए जाने के लिए अपात्र रखता है
  • प्रतिस्थापन मार्गदर्शन
  • पुराने और नए व्यवहार को समाहित करने वाले दस्तावेज़, निदान और परीक्षण
रजिस्ट्री अनुरक्षक योजना और भावी plugin निरीक्षक जाँचों का स्रोत है। यदि plugin-संबंधी व्यवहार बदलता है, तो एडाप्टर जोड़ने वाले उसी परिवर्तन में संगतता रिकॉर्ड जोड़ें या अपडेट करें। Doctor सुधार और माइग्रेशन संगतता को अलग से src/commands/doctor/shared/deprecation-compat.ts पर ट्रैक किया जाता है। उन रिकॉर्डों में पुराने कॉन्फ़िगरेशन आकार, इंस्टॉल-लेजर लेआउट और ऐसे सुधार शिम शामिल होते हैं, जिन्हें रनटाइम संगतता पथ हटाए जाने के बाद भी उपलब्ध रखने की आवश्यकता हो सकती है। रिलीज़ स्वीप में दोनों रजिस्ट्रियों की जाँच होनी चाहिए। किसी Doctor माइग्रेशन को केवल इसलिए न हटाएँ क्योंकि उससे मेल खाने वाला रनटाइम या कॉन्फ़िगरेशन संगतता रिकॉर्ड समाप्त हो गया है; पहले पुष्टि करें कि कोई समर्थित अपग्रेड पथ ऐसा नहीं है जिसे अब भी सुधार की आवश्यकता हो। रिलीज़ योजना के दौरान प्रत्येक प्रतिस्थापन एनोटेशन को भी पुनः सत्यापित करें, क्योंकि प्रदाताओं और चैनलों के कोर से बाहर जाने पर plugin स्वामित्व और कॉन्फ़िगरेशन का दायरा बदल सकता है।

अप्रचलन नीति

OpenClaw को किसी दस्तावेज़ीकृत plugin अनुबंध को उसी रिलीज़ में नहीं हटाना चाहिए जिसमें उसका प्रतिस्थापन प्रस्तुत किया जाता है। माइग्रेशन क्रम:
  1. नया अनुबंध जोड़ें।
  2. पुराने व्यवहार को नामित संगतता एडाप्टर के माध्यम से जोड़े रखें।
  3. जब plugin लेखक कार्रवाई कर सकें, तब निदान या चेतावनियाँ जारी करें।
  4. प्रतिस्थापन और समयरेखा का दस्तावेज़ीकरण करें।
  5. पुराने और नए, दोनों पथों का परीक्षण करें।
  6. घोषित माइग्रेशन अवधि पूरी होने तक प्रतीक्षा करें।
  7. केवल स्पष्ट ब्रेकिंग-रिलीज़ स्वीकृति मिलने पर हटाएँ।
अप्रचलित रिकॉर्डों में चेतावनी आरंभ होने की तिथि, प्रतिस्थापन, दस्तावेज़ लिंक और चेतावनी आरंभ होने के अधिकतम तीन महीने बाद की अंतिम हटाने की तिथि अवश्य शामिल होनी चाहिए। अनिश्चितकालीन हटाने की अवधि वाला कोई अप्रचलित संगतता पथ तब तक न जोड़ें, जब तक अनुरक्षक स्पष्ट रूप से यह निर्णय न लें कि यह स्थायी संगतता है और इसे इसके बजाय active चिह्नित न करें।

वर्तमान संगतता क्षेत्र

जुलाई 2026 के स्वीप ने समय-सीमा समाप्त हो चुके रूट SDK, मैनिफ़ेस्ट, प्रदाता, रनटाइम, रजिस्ट्री-फ़्लैग और plugin-स्वामित्व वाले वेब-कॉन्फ़िगरेशन उपनाम हटा दिए। Doctor माइग्रेशन अलग से ट्रैक होते रहते हैं, ताकि समर्थित अपग्रेड पथ अब भी पुराने कॉन्फ़िगरेशन की मरम्मत कर सकें। शेष दिनांकित संगतता क्षेत्र ये हैं:
  • माइग्रेशन गाइड में सूचीबद्ध अगस्त और सितंबर की SDK उपपथ अवधियाँ
  • api.on("deactivate", ...) और api.on("subagent_spawning", ...) हुक उपनाम
  • मेमोरी-विशिष्ट एम्बेडिंग पंजीकरण और beta.5 सेशन-स्टोर ब्रिज
  • नीचे वर्णित WhatsApp इनबाउंड कॉलबैक उपनाम
  • स्पष्ट चैनल लक्ष्य पार्सिंग और openclaw/plugin-sdk/messaging-targets
  • एम्बेडेड Pi एजेंट उपनाम
  • जारी किए गए एजेंट-हार्नेस SDK उपनाम, जिन्हें हटाने के लिए एक नया बाहरी रूप से दस्तावेज़ीकृत माइग्रेशन निर्णय लंबित है
सक्रिय, बिना तिथि वाले रजिस्ट्री रिकॉर्ड हटाने के दायित्व के बजाय समर्थित व्यवहार को समाहित करते हैं, जिनमें सक्रियण संकेत, plugin कैप्चर, बंडल किए गए plugin को सक्षम करना और जनरेट किया गया चैनल-कॉन्फ़िगरेशन फ़ॉलबैक शामिल हैं।

WhatsApp इनबाउंड कॉलबैक के फ़्लैट उपनाम

WhatsApp रनटाइम कॉलबैक WebInboundMessage प्रदान करते हैं: कैनोनिकल नेस्टेड event, payload, quote, group, और platform संदर्भ तथा जारी किए गए कॉलबैक फ़ील्ड के लिए अप्रचलित फ़्लैट उपनाम। नए कॉलबैक कोड को नेस्टेड संदर्भ पढ़ने चाहिए। स्वच्छ नेस्टेड कॉलबैक संदेश बनाने वाला कोड WebInboundCallbackMessage का उपयोग कर सकता है; ऐसे संगतता लिसनर जो अब भी पुराने फ़्लैट परीक्षण या plugin संदेश इंजेक्ट करते हैं, उन्हें LegacyFlatWebInboundMessage या WebInboundMessageInput का उपयोग करना चाहिए। फ़्लैट उपनाम 2026-08-30 तक उपलब्ध रहेंगे; यह अवधि केवल फ़्लैट उपनाम एक्सेस पर लागू होती है, नेस्टेड आकार पर नहीं, जो कैनोनिकल रनटाइम अनुबंध है। प्रत्येक फ़्लैट उपनाम का TypeScript @deprecated एनोटेशन उसके सटीक नेस्टेड प्रतिस्थापन का नाम बताता है। सामान्य उदाहरण:
  • id, timestamp, और isBatched, event के अंतर्गत जाते हैं।
  • body, mediaPath, mediaType, mediaFileName, mediaUrl, location, और untrustedStructuredContext, payload के अंतर्गत जाते हैं।
  • to, chatId, प्रेषक/स्वयं फ़ील्ड, sendComposing, reply(...), और sendMedia(...), platform के अंतर्गत जाते हैं।
  • replyTo* फ़ील्ड quote के अंतर्गत जाते हैं; समूह विषय/प्रतिभागी/उल्लेख फ़ील्ड group के अंतर्गत जाते हैं।
payload.untrustedStructuredContext को इनबाउंड प्रदाता पेलोड से निकाला जाता है। Plugins को इसके payload को प्रामाणिक मानने से पहले label, source, और type की जाँच करनी चाहिए।

WhatsApp इनबाउंड प्रवेश फ़ील्ड

स्वीकृत WhatsApp कॉलबैक संदेशों में admission होता है, जो संदेश को प्रवेश देने वाले अभिगम-नियंत्रण निर्णय के लिए सार्वजनिक रूप से सुरक्षित एनवेलप है। नए कॉलबैक कोड को पुराने शीर्ष-स्तरीय प्रवेश फ़ील्ड के बजाय msg.admission से प्रवेश तथ्य पढ़ने चाहिए। शीर्ष-स्तरीय फ़ील्ड 2026-08-30 तक उपलब्ध रहेंगे। प्रत्येक फ़ील्ड का TypeScript @deprecated एनोटेशन उसके प्रतिस्थापन का नाम बताता है:
  • from और conversationId, admission.conversation.id में जाते हैं।
  • accountId, admission.accountId में जाता है।
  • accessControlPassed, admission.ingress.decision === "allow" का एक व्युत्पन्न संगतता दृश्य है; उन संदेशों पर जिनमें पहले से admission मौजूद है, लेगेसी बूलियन लिखने से इनग्रेस ग्राफ़ दोबारा नहीं लिखा जाता।
  • chatType, admission.conversation.kind में जाता है।

Plugin निरीक्षक पैकेज

Plugin निरीक्षक को कोर OpenClaw रिपॉज़िटरी के बाहर एक अलग पैकेज/रिपॉज़िटरी के रूप में होना चाहिए, जो संस्करणित संगतता और मैनिफ़ेस्ट अनुबंधों द्वारा समर्थित हो। पहले दिन का CLI यह होना चाहिए:
इसे मैनिफ़ेस्ट/स्कीमा सत्यापन, जाँचा जा रहा अनुबंध संगतता संस्करण, इंस्टॉल/स्रोत मेटाडेटा जाँच, कोल्ड-पथ इंपोर्ट जाँच और अप्रचलन/संगतता चेतावनियाँ उत्सर्जित करनी चाहिए। CI एनोटेशन में स्थिर मशीन-पठनीय आउटपुट के लिए --json का उपयोग करें। OpenClaw कोर को ऐसे अनुबंध और फ़िक्सचर उपलब्ध कराने चाहिए जिनका निरीक्षक उपयोग कर सके, लेकिन मुख्य openclaw पैकेज से निरीक्षक बाइनरी प्रकाशित नहीं करनी चाहिए।

अनुरक्षक स्वीकृति लेन

OpenClaw plugin पैकेजों के विरुद्ध बाहरी निरीक्षक को सत्यापित करते समय इंस्टॉल किए जा सकने वाले पैकेज की स्वीकृति लेन के लिए Crabbox-समर्थित Blacksmith Testbox का उपयोग करें। पैकेज बनने के बाद इसे एक स्वच्छ OpenClaw चेकआउट से चलाएँ:
इस लेन को अनुरक्षकों के लिए वैकल्पिक रखें, क्योंकि यह एक बाहरी npm पैकेज इंस्टॉल करती है और रिपॉज़िटरी के बाहर क्लोन किए गए plugin पैकेजों का निरीक्षण कर सकती है। स्थानीय रिपॉज़िटरी गार्ड SDK एक्सपोर्ट मैप, संगतता रजिस्ट्री मेटाडेटा, अप्रचलित SDK-इंपोर्ट के क्रमिक उन्मूलन और बंडल किए गए एक्सटेंशन की इंपोर्ट सीमाओं को समाहित करते हैं; Testbox निरीक्षक प्रमाण पैकेज को उसी तरह समाहित करता है जैसे बाहरी plugin लेखक उसका उपयोग करते हैं।

रिलीज़ नोट्स

किसी संगतता पथ के removal-pending या removed में जाने से पहले, रिलीज़ नोट्स में लक्ष्य तिथियों और माइग्रेशन दस्तावेज़ों के लिंक के साथ आगामी plugin अप्रचलन शामिल होने चाहिए।