मल्टी-हार्नेस एडॉप्टर डिज़ाइन के भीतर

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

HarnessAdapter प्रोटोकॉल

प्रत्येक हार्नेस एडॉप्टर एक संरचनात्मक HarnessAdapter प्रोटोकॉल को लागू करता है। प्रोटोकॉल CLI और विक्रेता-विशिष्ट विवरणों के बीच की सीवन है। यह उन ऑपरेशनों की घोषणा करता है जिन्हें CLI आह्वान करता है और उस मेटाडेटा की जिसे CLI पढ़ता है:

• name — एडॉप्टर का पंजीकृत पहचानकर्ता।
• output_path — जहाँ मूर्त किया गया कॉन्फ़िग डिस्क पर उतरता है।
• install — हार्नेस-मूल कॉन्फ़िग को रेंडर करना और लिखना।
• uninstall — मूर्त किए गए कॉन्फ़िग को हटाना, साझा प्रोफ़ाइल को अछूता छोड़ते हुए।
• is_installed — रिपोर्ट करना कि हार्नेस का कॉन्फ़िग मौजूद है या नहीं।
• verify — प्रोफ़ाइल और डिस्क पर मौजूद कॉन्फ़िग के बीच विचलन का पता लगाना।

चूँकि अनुबंध एक typing.Protocol है, एक एडॉप्टर उसे आकार से संतुष्ट करता है, वंशानुक्रम से नहीं। CLI एडॉप्टरों को pyproject.toml में [project.entry-points."apothem.harnesses"] तालिका से importlib.metadata के माध्यम से गतिशील रूप से लोड करता है। एक हार्नेस जोड़ने का अर्थ है एक उप-पैकेज प्रकाशित करना जो प्रोटोकॉल को उजागर करता है — कोर डिस्पैचर में कोई संपादन नहीं।

प्रति एडॉप्टर एक उप-पैकेज

प्रत्येक एडॉप्टर src/apothem/harnesses/<name>/ के नीचे अपने स्वयं के उप-पैकेज में रहता है:

• __init__.py — <Name>Adapter वर्ग जो प्रोटोकॉल को लागू करता है और सहोदर एक्शन मॉड्यूल को प्रत्यायोजित करता है।
• install.py / uninstall.py / update.py / verify.py — प्रति-एक्शन कार्यान्वयन जिन्हें एडॉप्टर वर्ग आयात करता है और बुलाता है।
• materializer.py — एक वैकल्पिक materialize_native_config(profile) -> str जो साझा प्रोफ़ाइल को हार्नेस के मूल कॉन्फ़िग टेक्स्ट में रेंडर करता है।

प्रत्येक एक्शन को उसके अपने मॉड्यूल में बाँटना एडॉप्टर वर्ग को पतला रखता है: यह एक डिस्पैचर है जो प्रोटोकॉल विधियों को एक्शन फ़ंक्शनों से जोड़ता है। verify.py खोलने वाला पाठक ठीक उसी एक हार्नेस के लिए विचलन-पहचान तर्क देखता है, बिना किसी इंस्टॉल या अनइंस्टॉल के शोर से होकर गुज़रे।

तीन एडॉप्टर वर्ग

सत्रह हार्नेस सभी एक ही तरह से कॉन्फ़िगरेशन का उपभोग नहीं करते। Apothem उन्हें इस आधार पर तीन वर्गों में छाँटता है कि प्रोफ़ाइल को हार्नेस तक पहुँचने से पहले कितने रूपांतरण की आवश्यकता है।

वर्ग I — कच्चा प्रसार

हार्नेस उन्हीं कलाकृतियों का उपभोग करता है जिन्हें Apothem पहले से ही लिखता है — सपाट .md नियम, agents, hooks — बिना किसी रेंडरिंग चरण के। एडॉप्टर कच्चे टेम्पलेट को हार्नेस के कॉन्फ़िग वृक्ष में कॉपी करता है। यहाँ कोई materializer.py नहीं है, क्योंकि कुछ भी रेंडर नहीं होता; प्रोफ़ाइल की कलाकृतियाँ ही आउटपुट हैं।

वर्ग II-A — कच्चा साथ में विक्रेता टेम्पलेट

हार्नेस Apothem की कच्ची कलाकृतियों AND विक्रेता-विशिष्ट टेम्पलेट फ़ाइलों के एक समुच्चय (सेटिंग्स, मैनिफ़ेस्ट, या स्कैफ़ोल्ड फ़ाइलें जिनकी हार्नेस को आवश्यकता होती है) का उपभोग करता है। एडॉप्टर कच्ची कलाकृतियों और विक्रेता टेम्पलेट को एक साथ कॉपी करता है। विक्रेता टेम्पलेट एडॉप्टर के साथ-साथ एक templates/ डायरेक्टरी के नीचे रहते हैं।

वर्ग II-B — प्रोफ़ाइल-रेंडर्ड

हार्नेस साझा प्रोफ़ाइल के संरचित फ़ील्ड्स से रेंडर की गई एक एकल मूल कॉन्फ़िग फ़ाइल चाहता है। एडॉप्टर का materializer.py प्रोफ़ाइल को पढ़ता है और हार्नेस-मूल टेक्स्ट उत्सर्जित करता है — एक Hermes config.yaml, एक Open-Claw openclaw.json, एक OpenCode opencode.json, या एक Qwen Code settings.json। वर्ग II-B वह जगह है जहाँ प्रारूप-समाधान का काम केंद्रित होता है; कन्वेंशन अभिसरण का गहन विश्लेषण इसे विस्तार से कवर करता है।

claude-code: पूर्ण-सतह संदर्भ एडॉप्टर

claude-code एडॉप्टर सबसे व्यापक कॉन्फ़िग सतह — नियम, agents, hooks, output-styles, सेटिंग्स, और कन्वेंशन डायरेक्टरियाँ — के लिए संदर्भ कार्यान्वयन है। यह वर्ग II-A से संबंधित है: यह Apothem के कच्चे टेम्पलेट का प्रसार करता है और कन्वेंशन डायरेक्टरियों को समतल करता है, और यह src/apothem/harnesses/claude_code/templates/ के नीचे विक्रेता सेटिंग्स टेम्पलेट जहाज़ी करता है। यह कोई materializer.py नहीं रखता — यह प्रोफ़ाइल से कोई मूल कॉन्फ़िग फ़ाइल रेंडर नहीं करता; यह कलाकृतियों और कन्वेंशन डायरेक्टरियों का सीधे प्रसार करता है।

एक जानबूझकर खींची गई सीमा: claude-code एडॉप्टर CLAUDE.md का प्रबंधन नहीं करता। वह फ़ाइल ऑपरेटर के स्वामित्व वाला क्षेत्र है। Apothem आसपास की कॉन्फ़िग सतह — नियम, hooks, सेटिंग्स — को मूर्त करता है और ऑपरेटर की अपनी CLAUDE.md आवाज़ को अछूता छोड़ देता है। एक एडॉप्टर जो इसे अधिलेखित करता, वह प्रत्येक apothem install पर हाथ से लिखे प्रोजेक्ट निर्देशों को मिटा देता, इसलिए एडॉप्टर डायरेक्टरी की सीमा पर रेखा खींचता है और रुक जाता है।

यह समरूपता क्यों मायने रखती है

प्रोटोकॉल ऑपरेटर को सत्रह उपकरणों के पार एक मानसिक मॉडल देता है। चाहे लक्ष्य एक एकल फ़ाइल रेंडर करे या किसी डायरेक्टरी वृक्ष को समतल करे, apothem install, apothem verify, apothem uninstall एक ही तरह व्यवहार करते हैं। विक्रेता भिन्नताएँ एडॉप्टर उप-पैकेजों के भीतर, प्रोटोकॉल के पीछे रहती हैं — जहाँ उनका स्थान है।

ऑपरेटर के लिए संदर्भ हार्नेस पर और प्रोफ़ाइल मॉडल अवधारणाएँ में पढ़ें।