कोहोर्ट पैकेजिंग अनुबंध

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

आर्टिफ़ैक्ट

कोहोर्ट मैनिफ़ेस्ट का आकार

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

• 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/ प्रविष्टि) से मेल खाता है।

कोहोर्ट गिनना

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

प्रति-हार्नेस मूल लक्ष्यों को हल करना (कोई पुनर्व्युत्पत्ति नहीं)

कोहोर्ट मैनिफ़ेस्ट हार्नेस मैपिंग को पुनः नहीं बताता। इसके बजाय, 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 कोहोर्ट skill source: "skills/" वाली harnesses.claude_code.install प्रविष्टि के माध्यम से target: "${HARNESS_ROOT}/skills/" में हल होती है। वही skill opencode के लिए ${HARNESS_ROOT}/skills/ में हल होती है; gemini_cli के लिए ${PROJECT_ROOT}/.gemini/skills/ में। उपभोक्ता कभी भी हार्नेस लक्ष्य नहीं गढ़ते — वे उन्हें खोजते हैं।

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

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

plugin.schema.json एक plugin.json का वर्णन करता है — एक आवश्यक name, SemVer version, और description के साथ कैटलॉग सदस्यों (skills / commands / agents / hooks / rules) का एक स्व-वर्णनात्मक बंडल। एक प्लगइन मैनिफ़ेस्ट वह इकाई है जिसे एक हार्नेस एडॉप्टर अपनी मूल प्लगइन सतह में मूर्त रूप देता है; कोहोर्ट चुनते हैं कि एक प्लगइन कौन-से सदस्यों को वहन करता है, और प्रसार मैनिफ़ेस्ट यह हल करता है कि वे सदस्य प्रति हार्नेस कहाँ उतरते हैं।

पैकेजिंग निर्णय — एक छत्र बंडल, तार्किक कोहोर्ट

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

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

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