हार्नेस-पार नियम-अभिसरण

सत्रह हार्नेस, और कॉन्फ़िगरेशन कहाँ रहता है तथा किस रूप में होता है, इस पर सत्रह अलग-अलग राय। Apothem का काम ऑपरेटर के वर्कफ़्लो को इन सबमें एक-समान महसूस कराना है — आप नियम एक बार लिखते हैं, और वे एक ही तरह व्यवहार करते हैं, चाहे आप Claude Code की ओर बढ़ें या Cursor की या Gemini CLI की। यह पोस्ट उन दो भिन्नताओं को कवर करती है जिन्हें Apothem सुलझाता है: कॉन्फ़िगरेशन प्रारूप और प्रवर्तन सतह।

प्रारूप की भिन्नता

प्रत्येक हार्नेस अपने नियम एक अलग फ़ाइल-रूप से पढ़ता है। Apothem की प्रोफ़ाइल ऑपरेटर के आशय को एक तटस्थ रूप में रखती है; प्रत्येक अडैप्टर उस आशय को अपने हार्नेस के अपेक्षित रूप में रेंडर करता है।

सपाट .md हार्नेस नियमों को ज्यों-का-त्यों लेता है। .mdc हार्नेस को प्रत्येक नियम के चारों ओर Cursor मेटाडेटा हेडर लपेटने की आवश्यकता होती है। एकल-फ़ाइल हार्नेस को पूरे नियम-सेट को स्थिर अनुभाग-क्रम के साथ एक दस्तावेज़ में समतल करने की आवश्यकता होती है, ताकि ऑपरेटर लक्ष्य चाहे जो हो, उन्हीं नियमों को उसी अनुक्रम में पढ़े। तटस्थ प्रोफ़ाइल सत्य का एकमात्र स्रोत है; भिन्नता पूरी तरह प्रत्येक अडैप्टर के रेंडरिंग चरण में बसती है।

अनुभाग-क्रम अभिसरण का लंगर है

कई नियमों को एक दस्तावेज़ में समतल करना उन्हें हार्नेस-दर-हार्नेस फेरबदल कर देने का जोखिम रखता है, जिससे वही नियम AGENTS.md में GEMINI.md की तुलना में भिन्न क्रम में उतरते हैं। Apothem क्रम को प्रोफ़ाइल स्तर पर तय करता है: नियम-सेट का एक घोषित अनुक्रम होता है, और प्रत्येक एकल-फ़ाइल अडैप्टर उसी क्रम में उसे क्रमवार चलता है। जो ऑपरेटर एक हार्नेस में याद करता है कि «नामकरण नियम कमिट नियमों से पहले आते हैं», वह हर दूसरे हार्नेस में भी वही अनुक्रम पाता है। अभिसरण रेंडरिंग की कोई दुर्घटना नहीं है — यह वह गुण है जिसे प्रोफ़ाइल कीलित करती है।

प्रवर्तन की भिन्नता

कॉन्फ़िगरेशन प्रारूप दृश्यमान आधा हिस्सा है। कठिन आधा हिस्सा प्रवर्तन है: किसी नियम का उस क्षण उत्तरदायित्व कैसे निभाया जाता है जब ऑपरेटर (या एजेंट) कार्य करता है।

नेटिव PreToolUse हुक

claude-code, codex, और qwen-code नेटिव हुक सतहें उजागर करते हैं। एक PreToolUse हुक किसी टूल कॉल के निष्पादित होने से पहले प्रज्वलित होता है, उसका निरीक्षण करता है, और उसे अवरुद्ध या पुनर्लिखित करता है। यह वास्तविक-समय प्रवर्तन है: नियोजन कलाकृतियों को किसी वैश्विक स्थान पर लिखने के विरुद्ध एक नियम ऐसा हुक बन जाता है जो लेखन के डिस्क को छूने से पहले ही उसे अस्वीकार कर देता है। Apothem इन हुक को सीधे हार्नेस की हुक कॉन्फ़िगरेशन में मूर्त रूप देता है, जिससे नियम हार्नेस रनटाइम द्वारा प्रवर्तित होता है।

अन्यत्र रैपर-आधारित अनुशासन

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

व्यवहार में अभिसरण का क्या अर्थ है

ऑपरेटर एक नियम लिखता है। Apothem उसे सत्रह प्रारूपों में रेंडर करता है और उसके साथ वह सबसे मज़बूत प्रवर्तन जोड़ता है जो प्रत्येक हार्नेस समर्थन करता है — जहाँ सतह मौजूद है वहाँ नेटिव हुक, जहाँ नहीं है वहाँ निर्देश-पाठ। वर्कफ़्लो अभिसरित होता है; गारंटियाँ प्रत्येक हार्नेस के अनुसार ईमानदारी से बताई जाती हैं।

यही कारण है कि apothem verify हर मोर्चे पर मायने रखता है: जहाँ कोई रनटाइम हुक विचलन नहीं पकड़ सकता, वहाँ ऑपरेटर verify चलाकर ऐसी हार्नेस कॉन्फ़िगरेशन का पता लगाता है जो प्रोफ़ाइल से विचलित हो गई है। verify कमांड हर उस हार्नेस के लिए अभिसरण का अंतिम-कवच है जिसके पास नेटिव प्रवर्तन नहीं है।

प्रति-हार्नेस प्रवर्तन सतह को हार्नेस में और अडैप्टर यांत्रिकी को अडैप्टर डिज़ाइन गहन-विश्लेषण में पढ़ें।