समूह पैकेजिंग अनुबंधCopy Anchor Link

यह दस्तावेज़ समूह पैकेजिंग और प्लगइन मैनिफ़ेस्ट के लिए स्थिर, डाउनस्ट्रीम-उपभोग्य अनुबंध निर्दिष्ट करता है। कोई उपभोक्ता इस अनुबंध को पढ़कर समूह गिनता है और उनके प्रति-हार्नेस नेटिव टारगेट मैपिंग को फिर से व्युत्पन्न किए बिना हल करता है।

आर्टिफ़ैक्टCopy Anchor Link

समूह मैनिफ़ेस्ट का आकारCopy Anchor Link

समूह मैनिफ़ेस्ट तीन कुंजियों वाला एक शीर्ष-स्तरीय ऑब्जेक्ट है:

• version — मैनिफ़ेस्ट की SemVer स्ट्रिंग।
• cohorts[] — प्रति समूह एक प्रविष्टि। प्रत्येक प्रविष्टि में id (बंद समुच्चय core | developer | security | research | ai-engineering | full से), name, description, और members (एक ऑब्जेक्ट जो सदस्य पहचानकर्ताओं को कैटलॉग प्रकार के अनुसार समूहबद्ध करता है: skills / agents / commands / rules / hooks) होते हैं।
• per_harness_targets — समाधान अनुबंध (नीचे)।

प्रत्येक सदस्य पहचानकर्ता एक स्थिर kebab-case नाम है जो src/apothem/ के अंतर्गत किसी वास्तविक आर्टिफ़ैक्ट से मेल खाता है (skills/<name>/, agents/<name>.md, commands/<name>.md, rules/<name>.md, या कोई हुक प्रविष्टि — या तो एक निष्पादन-योग्य hooks/<name>.py या hooks/messages/<name>.md पर स्थित एक परामर्शी संदेश-संदर्भ जो डिस्पैचर के माध्यम से पहुँचाया जाता है)।

समूह गिननाCopy Anchor Link

कोई उपभोक्ता cohort-manifest.yaml लोड करता है, उसे cohort.schema.json के विरुद्ध सत्यापित करता है, फिर cohorts[] पर पुनरावृत्ति करता है। प्रत्येक समूह के लिए वह हर कैटलॉग प्रकार के सदस्य पहचानकर्ता प्राप्त करने हेतु members.<type> पढ़ता है।

प्रति-हार्नेस नेटिव टारगेट हल करना (कोई पुनर्व्युत्पत्ति नहीं)Copy Anchor Link

समूह मैनिफ़ेस्ट हार्नेस मैपिंग को दोहराता नहीं है। इसके बजाय, per_harness_targets.source lib/propagation-manifest.yaml की ओर इंगित करता है, जो सत्य का एकमात्र स्रोत है। समाधान नियम:

कैटलॉग प्रकार T (skills, agents, commands, rules, hooks में से एक) के किसी समूह सदस्य और किसी टारगेट हार्नेस H (per_harness_targets.harnesses में सूचीबद्ध हार्नेसों में से एक) के लिए, नेटिव प्लगइन टारगेट lib/propagation-manifest.yaml में harnesses.H.install के अंतर्गत उस प्रविष्टि का target फ़ील्ड है जिसका source T/ से मेल खाता है।

उदाहरण के लिए, claude_code के लिए इंस्टॉल की गई कोई core समूह स्किल source: "skills/" वाली harnesses.claude_code.install प्रविष्टि के माध्यम से target: "${HARNESS_ROOT}/skills/" में हल होती है। वही स्किल opencode के लिए ${HARNESS_ROOT}/skills/ में हल होती है; gemini_cli के लिए ${PROJECT_ROOT}/.gemini/skills/ में। उपभोक्ता कभी भी हार्नेस टारगेट नहीं गढ़ते — वे उन्हें देखकर निकालते हैं।

${HARNESS_ROOT} / ${PROJECT_ROOT} प्लेसहोल्डर इंस्टॉल समय पर प्रत्येक हार्नेस अडैप्टर द्वारा हल किए जाते हैं; समूह उपभोक्ता हल किए गए target को शब्दशः वैसा ही लेते हैं।

प्लगइन मैनिफ़ेस्ट की भूमिकाCopy Anchor Link

plugin.schema.json एक plugin.json का वर्णन करता है — कैटलॉग सदस्यों (skills / commands / agents / hooks / rules) का एक स्व-वर्णनात्मक बंडल, जिसमें एक आवश्यक name, SemVer version, और description होता है। वैकल्पिक मेटाडेटा में displayName (वह नाम जो name के स्थान पर दिखाया जाता है) और प्लगइन-डायरेक्टरी सूचीकरण फ़ील्ड आते हैं: documentationUrl, supportUrl, privacyPolicyUrl और termsOfServiceUrl, जिनमें से प्रत्येक एक https:// URL है, साथ ही प्लगइन के भीतर एक icon पथ। उत्पन्न Claude Code पैकेज displayName, documentationUrl और supportUrl सेट करता है। Anthropic की डायरेक्टरी सूचीकरण फ़ील्ड पढ़ती है और Claude Code लोड के समय उन्हें अनदेखा करता है। claude.ai मार्केटप्लेस सिंक दोनों लिंक को अपरिचित कुंजियों के रूप में रिपोर्ट करता है और उन्हें हटा देता है, इसलिए वहाँ मार्केटप्लेस "1 with warnings" दिखाता है। वह चेतावनी अपेक्षित है, और प्लगइन बिना बदलाव के लोड होता है। प्लगइन मैनिफ़ेस्ट वह इकाई है जिसे कोई हार्नेस अडैप्टर अपनी नेटिव प्लगइन सतह में मटेरियलाइज़ करता है; समूह यह चुनते हैं कि कोई प्लगइन कौन-से सदस्य वहन करता है, और प्रसार मैनिफ़ेस्ट यह हल करता है कि वे सदस्य प्रति हार्नेस कहाँ उतरते हैं।

पैकेजिंग निर्णय — एक छत्र बंडल, तार्किक समूहCopy Anchor Link

समूह एक तार्किक चयन परत (यह मैनिफ़ेस्ट) हैं, न कि अलग-अलग, स्वतंत्र रूप से इंस्टॉल-योग्य बंडलों का समुच्चय। Apothem पूरा कैटलॉग वहन करने वाला एक छत्र बंडल शिप करता है; समूह मैनिफ़ेस्ट उपभोक्ता को एक सुसंगत उपसमुच्चय चुनने देता है, और प्रसार मैनिफ़ेस्ट यह हल करता है कि प्रत्येक चयनित सदस्य प्रति हार्नेस कहाँ उतरता है।

कैटलॉग को प्रति-समूह अलग बंडलों में विभाजित करना (उदाहरण के लिए प्रति developer / security / research परिवार एक बंडल) प्राथमिक वितरण सतह के प्रलेखित मेटा-प्लगइन सिमलिंक पैटर्न के माध्यम से रिपॉज़िटरी-स्तर के दोहराव के बिना संभव है: एक मार्केटप्लेस कैटलॉग कई समूह प्लगइन सूचीबद्ध करता है, और प्रत्येक समूह प्लगइन डायरेक्टरी प्रतियों के बजाय एकल-स्रोत साझा कैटलॉग में सिमलिंक रखती है। जब कोई समूह इंस्टॉल होता है, तो हार्नेस मार्केटप्लेस के भीतर के प्रत्येक सिमलिंक को डीरेफ़रेंस करता है — टारगेट की सामग्री को उस समूह के कैश में कॉपी करते हुए — ताकि इंस्टॉल किया गया समूह स्व-निहित हो, जबकि रिपॉज़िटरी सिमलिंक से जुड़ा सत्य का एक ही स्रोत बनाए रखती है (अतिरेक के बजाय जुड़ाव, ठीक वैसे ही जैसे डीडुप अनुशासन पसंद करता है)। पहले की यह व्याख्या कि समूह बंडल कैटलॉग को "यांत्रिक रूप से दोहराते" हैं, इंस्टॉल-समय कैश दोहराव (हार्नेस की सामान्य प्रति-प्लगइन प्रति) को रिपॉज़िटरी दोहराव के साथ मिला देती थी; सिमलिंक पैटर्न बाद वाले से बचता है।

Apothem वर्तमान में एक छत्र बंडल इसलिए शिप करता है क्योंकि वह सबसे सरल वितरण सतह है, इसलिए नहीं कि समूह यांत्रिक रूप से असंभव हैं। प्रति-समूह रूप अपनाना एक वास्तविक UX-और-रखरखाव समझौता है, डीडुप उल्लंघन नहीं: लाभ एक अधिक बारीक "केवल यही परिवार इंस्टॉल करें" अनुभव है; लागतें हैं N समूह सिमलिंक डायरेक्टरियों और उनकी मार्केटप्लेस प्रविष्टियों का रखरखाव, एक बड़ी अनुरूपता / परीक्षण / गोल्डन सतह, और प्रति-समूह इंस्टॉल-समय कैश प्रतियाँ। ऊपर की तार्किक-समूह परत एकल बंडल से ही "केवल वही इंस्टॉल करें जिसकी आपको आवश्यकता है" वाला चयन परिणाम पहले से देती है; जब भी अधिक बारीक इंस्टॉल UX चाहिए हो, प्रति-समूह पैकेजिंग अगला कदम है।