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

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

HarnessAdapter प्रोटोकॉलCopy Anchor Link

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

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

चूँकि अनुबंध एक typing.Protocol है, एक अडैप्टर उसे आकार से संतुष्ट करता है, वंशानुक्रम से नहीं। रनटाइम पर CLI हर अडैप्टर को एक स्थिर रजिस्ट्री से हल करता है — src/apothem/lib/harness_registry_data.py में HARNESS_REGISTRY तालिका, जिसे harness_registry.py रनटाइम पर आधिकारिक घोषित करता है — इसलिए हर अडैप्टर एक सादे चेकआउट से लोड हो जाता है, sys.path पर इंस्टॉल किए गए किसी भी एंट्री-पॉइंट मेटाडेटा के बिना। pyproject.toml में [project.entry-points."apothem.harnesses"] तालिका और फ़ाइल-सिस्टम discover_adapters() स्वीप एक अनुरूपता समता जाँच हैं, रनटाइम रिज़ॉल्वर नहीं: एक परीक्षण अभिकथित करता है कि खोजे गए अडैप्टरों का समुच्चय स्थिर रजिस्ट्री के बराबर है, इसलिए कोई परिपाटी-सही किंतु अपंजीकृत अडैप्टर चुपचाप हल होने के बजाय कवरेज प्रतिगमन के रूप में उभरता है। इसलिए एक हार्नेस जोड़ने का अर्थ है उसे रजिस्ट्री डेटा में पंजीकृत करना (और पैकेजिंग समता के लिए उसे एंट्री-पॉइंट तालिका में प्रतिबिंबित करना) — यदि दोनों में से कोई एक छूट जाए तो समता परीक्षण स्पष्ट रूप से विफल हो जाता है।

प्रति अडैप्टर एक उप-पैकेजCopy Anchor Link

प्रत्येक अडैप्टर 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 खोलने वाला पाठक ठीक उसी एक हार्नेस के लिए विचलन-पहचान तर्क देखता है, बिना किसी इंस्टॉल या अनइंस्टॉल के शोर से होकर गुज़रे।

तीन अडैप्टर वर्गCopy Anchor Link

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

वर्ग I — कच्चा प्रसारCopy Anchor Link

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

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

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

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

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

claude-code: पूर्ण-सतह अडैप्टरCopy Anchor Link

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

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

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

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

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