install-maintenance-graft-rtk-ponytail-lite

प्रॉम्प्ट

# Verified Installation and Maintenance — Graft + RTK + Ponytail lite

आप वर्तमान रिपॉजिटरी में इस स्टैक को इंस्टॉल, अपडेट, रिपेयर, या सत्यापित करने का काम कर रहे हैं:

- Graft: कोड समझ, लोकल ग्राफ, और LSP संवर्धन।
- RTK: टर्मिनल शोर कम करना।
- Ponytail: लाइट पॉलिसी, जब संगत हो तो नेटिव इंटीग्रेशन के साथ।

सबसे पहले एक रीड-ओनली इन्वेंटरी से शुरू करें। फिर नीचे दिए गए गायब प्रश्न पूछें।
उत्तर मिलने के बाद, अधिकृत ऑपरेशनों को अंतिम जांच तक करें।

इंस्टॉलेशन शुरू न करें जब तक क्लाइंट्स और स्कोप निर्धारित न हो जाएं।
इस बातचीत में पहले से दिए गए निर्णय के लिए फिर से प्रश्न न पूछें।

## 1. इन्वेंटरी, फिर उपयोगकर्ता का चयन

### बिना संशोधन के इन्वेंटरी

पहचान करें:

- OS, आर्किटेक्चर, शेल, पर्यावरण: लोकल मशीन, WSL, SSH, कंटेनर;
- रिपॉजिटरी रूट, वर्कट्री, Git स्थिति और चल रही Git ऑपरेशंस;
- Git, Node, npm, RTK, Graft, और उपलब्ध क्लाइंट्स के वास्तविक पाथ, संस्करण, और इंस्टॉलेशन विधि;
- Claude Code, Codex, Kimi, Cursor Agent CLI, और Cursor IDE अलग-अलग;
- Gemini, Copilot CLI, या अन्य क्लाइंट्स जो पहले से मौजूद हैं, वैकल्पिक लक्ष्यों के रूप में;
- वास्तव में उपयोग किए गए कॉन्फ़िगरेशन डायरेक्टरीज़, रीडायरेक्शन वेरिएबल्स,
  और कोई भी ऑर्केस्ट्रेटर जैसे AgentsRoom;
- मौजूदा उपयोगकर्ता, प्रोजेक्ट, प्लगइन, और विरासत में मिले हुक कॉन्फ़िगरेशन।

`agent` की पहचान Cursor के रूप में मानने से पहले सत्यापित करें।
मौजूद बाइनरी प्रमाणित नहीं करता कि वह प्रमाणीकृत है, हुक कार्यशील है,
या MCP लोड हो रहा है।

इस इन्वेंटरी के दौरान स्वचालित अपडेट, कनेक्शन, या इंस्टॉलेशन न चलाएं।
कोई भी गुप्त मान प्रकाशित न करें।

एक संक्षिप्त तालिका प्रस्तुत करें:
Client | Binary/version | Effective configuration | Known status.

### एक ही बैच में पूछने वाले प्रश्न

केवल उन प्रश्नों को पूछें जिनके उत्तर गायब हैं:

1. ऑपरेशन:
   - गायब घटकों को इंस्टॉल करें और संगत संस्करण रखें।
   - स्टैक को सत्यापित स्थिर संस्करणों तक अपडेट करें।
   - मौजूदा इंस्टॉलेशन की मरम्मत करें जबकि उसके संस्करण बनाए रखें।
   - केवल सत्यापन, बिना संशोधन के।

2. क्लाइंट्स:
   - सभी पता किए गए क्लाइंट्स।
   - वास्तव में पता किए गए सूची से चयन।
   - कुछ अनुपस्थित क्लाइंट्स के लिए भी कॉन्फ़िगरेशन तैयार करें।

3. इंटीग्रेशन स्कोप:
   - साझा प्रोजेक्ट: रिपॉजिटरी के लिए पोर्टेबल कॉन्फ़िगरेशन।
   - व्यक्तिगत प्रोजेक्ट: इस रिपॉजिटरी के लिए सक्रियण, बिना संस्करण वाले लोकल फाइल्स।
   - ग्लोबल उपयोगकर्ता: इस उपयोगकर्ता के प्रोजेक्ट्स के लिए सक्रियण।
   - मिश्रित: क्लाइंट या घटक द्वारा अलग-अलग चयन।

यदि स्कोप मिश्रित है, तो केवल आवश्यक स्पष्टीकरण पूछें।

अपडेट के लिए, यदि पहले से ज्ञात नहीं है तो किसी भी संस्करण प्रतिबंध के लिए भी पूछें।
अन्यथा, स्पष्ट स्थिर संस्करण प्रस्तावित करें।

क्लाइंट एप्लिकेशन स्वयं इंस्टॉल या अपडेट न करें:
यह ऑपरेशन Graft, RTK, Ponytail, और उनकी आवश्यक निर्भरताओं से संबंधित है।
एक पुराना क्लाइंट आवश्यक संस्करण और शेष कार्रवाई के साथ रिपोर्ट किया जाता है।

### विकल्पों को ठोस बनाएं

लिखने से पहले, नियोजित परिणाम दिखाएं:

Component/client | Target version | Scope | Targeted files | Shared effect | Fallback

विशेष रूप से समझाएं:

- उपयोगकर्ता स्तर पर इंस्टॉल किया गया एक executable कई रिपॉजिटरीज़ की सेवा कर सकता है।
- इस executable को अपडेट करने से इसके सभी लोकल उपयोगकर्ता प्रभावित होते हैं।
- एक प्लगइन का ग्लोबल कैश हो सकता है लेकिन सक्रियण प्रति प्रोजेक्ट हो।
- प्रति प्रोजेक्ट हुक फिर भी साझा स्थिति का उपयोग कर सकता है।
- Graft इंडेक्स रिपॉजिटरी/वर्कट्री के लिए विशिष्ट रहता है।
- एक ऑर्केस्ट्रेटर द्वारा प्रदान की गई ग्लोबल कॉन्फ़िगरेशन प्रोजेक्ट के लिए पृथक हो सकती है:
  इसके वास्तविक स्कोप की जांच करें, केवल नाम नहीं।

एक बार विकल्प प्राप्त हो जाने पर, बिना बार-बार पुष्टि के आगे बढ़ें।
केवल तब नया निर्णय मांगें जब कोई सीमा स्कोप विस्तार या भौतिक समाधान परिवर्तन की मांग करे।

## 2. निष्पादन नियम

क्रम:
इन्वेंटरी → चयन → बैकअप → RTK → Graft/LSP → Ponytail →
निर्देश → सत्यापन → रिपोर्ट।

रिपॉजिटरी निर्देशों और प्रशासित नीतियों का सम्मान करें।
यदि कोई फाइल AgentsRoom या किसी अन्य ऑर्केस्ट्रेटर द्वारा प्रबंधित है,
तो उसके आधिकारिक तंत्र का उपयोग करें; उसकी उत्पन्न फाइलों को सीधे संशोधित न करें।

प्रत्येक संशोधन से पहले:

- JSON/JSONC/TOML कॉन्फ़िगरेशन के फॉर्मेट और संरचना को मान्य करें;
- प्रभावित फाइलों का रिपॉजिटरी के बाहर बैकअप लें, सीमित पहुंच के साथ;
- रोलबैक के लिए आवश्यक संस्करण और तत्व रिकॉर्ड करें;
- जब उपलब्ध हो तो इंस्टॉलर के ड्राई-रन की समीक्षा करें।

एक अमान्य फाइल को कभी खाली कॉन्फ़िगरेशन से प्रतिस्थापित न करें।

अन्य MCPs, हुक्स, अनुमतियाँ, निर्देश, टिप्पणियाँ जब संभव हो, और स्थिति पंक्तियों को संरक्षित करते हुए कॉन्फ़िगरेशन मर्ज करें।
स्वीकृति नियम या ट्रस्ट फिंगरप्रिंट न बदलें।

पूर्व-मौजूद Git परिवर्तनों को संरक्षित करें। कोई कमिट, पुश, रीसेट,
क्लीन, स्टैश, या एप्लिकेशन कोड परिवर्तन न करें।
असुलझे संघर्ष या चल रही Git ऑपरेशन की स्थिति में,
रिपॉजिटरी में लिखना निलंबित करें; स्वतंत्र डायग्नोस्टिक्स जारी रखें।

Graphify, CodeGraph, Caveman, या Headroom इंस्टॉल न करें।
एक पुरानी टकराव वाली इंटीग्रेशन केवल सटीक पहचान, बैकअप,
और अधिकृत स्कोप के भीतर हटाई जाती है।
किसी टूल को जो कहीं और उपयोग हो रहा है, ग्लोबली अनइंस्टॉल न करें।

एक त्रुटि उसके निर्भर चरणों को ब्लॉक करती है, अन्य स्वतंत्र क्लाइंट्स को नहीं।
सीमा को बायपास करने के लिए किसी चरण को सफल घोषित न करें।

## 3. क्षमताएं और स्कोप: कॉन्फ़िगर करने से पहले सत्यापित करें

इंस्टॉल किए गए संस्करणों की मदद और उन प्रकाशित संस्करणों के दस्तावेज़ देखें जिन्हें आप उपयोग करेंगे:

- https://github.com/rtk-ai/rtk
- https://github.com/trailhq/Graft
- https://github.com/DietrichGebert/ponytail
- प्रत्येक चयनित क्लाइंट का आधिकारिक दस्तावेज़।

मुख्य/develop शाखा ऐसी विशेषताएं वर्णित कर सकती है जो रिलीज़ में नहीं हैं।
किसी संदिग्ध विकल्प के लिए, रिलीज़, मदद, या वितरित कोड जांचें।

प्रत्येक इंटीग्रेशन के लिए स्थापित करें:

Client | Available project hooks | Compatible installer |
Activation scope | State scope | Proof

भ्रमित न हों:
"क्लाइंट प्रोजेक्ट हुक स्वीकार करता है"
और
"इस टूल का इंस्टॉलर जानता है कि उन्हें प्रोजेक्ट स्तर पर कैसे इंस्टॉल करना है।"

वर्तमान संस्करणों में पुनः सत्यापित करने के लिए चेकपॉइंट्स:

- Claude: उपयोगकर्ता सेटिंग्स, साझा परियोजना, और स्थानीय परियोजना।
- Cursor: उपयोगकर्ता और परियोजना हुक; IDE और CLI को अलग-अलग परीक्षण करें।
- Codex: उपयोगकर्ता/परियोजना कॉन्फ़िगरेशन और प्लगइन सक्रियण;
  वास्तव में उपलब्ध हुक तंत्रों को सत्यापित करें।
- Kimi: प्रति-परियोजना हुक कॉन्फ़िगरेशन मानने से बचें;
  उपयोगकर्ता कॉन्फ़िगरेशन, परियोजना निर्देश, और लॉन्च विकल्पों में अंतर करें।
- Gemini/Copilot: चयनित होने पर उनके अपने तंत्रों को सत्यापित करें।

यदि इंस्टॉलर अनुरोधित स्कोप का सम्मान नहीं करता है:

1. एक उपयुक्त आधिकारिक विकल्प खोजें।
2. अन्यथा, उसी एडेप्टर की प्रलेखित मैनुअल कॉन्फ़िगरेशन का उपयोग करें,
   केवल यदि इसका प्रोटोकॉल और पथ संगत रहते हैं।
3. अन्यथा, स्पष्ट निर्देश/प्रिफिक्स द्वारा फॉलबैक का उपयोग करें।
4. कभी भी चुपचाप वैश्विक में स्विच न करें।

स्थानीय समकक्ष जोड़ने से पहले विरासत में मिली वैश्विक हुक्स का निरीक्षण करें:
वे एक-दूसरे को प्रतिस्थापित करने के बजाय जमा हो सकते हैं।
सुरक्षा हुक्स को संरक्षित करें। जो वैश्विक प्रभाव सक्रिय रहते हैं, उनकी रिपोर्ट करें।

## 4. RTK

मूल `rtk-ai/rtk`, संस्करण, सहायता, कॉन्फ़िगरेशन
और `rtk gain` की जांच करें। `gain` विफलता आधार या अनुमतियों से आ सकती है:
यह खराब पैकेज का पर्याप्त प्रमाण नहीं है।

यदि उपयुक्त हो तो पहले से उपयोग किए गए प्रबंधक से इंस्टॉल या अपडेट करें।
सूत्र या पैकेज की उत्पत्ति और प्राप्त संस्करण की जांच करें।
समानांतर इंस्टॉलेशन और अनावश्यक PATH परिवर्तनों से बचें।
`cargo install rtk` को अंधाधुंध न चलाएं।

चयनित संस्करण के लिए `rtk init --help` देखें।
क्लाइंट और स्कोप द्वारा विकल्प चुनें; दस्तावेज़ उदाहरण से
`-g` को स्वचालित रूप से न कॉपी करें।

यह न मानें कि Codex एक सरल निर्देश है,
या कि इसमें हमेशा हुक होता है: यह RTK संस्करण पर निर्भर करता है।
प्रारंभिक विकल्पों के बीच असंगतताओं की भी जांच करें।

वास्तव में पढ़ी गई कॉन्फ़िगरेशन में, बहिष्करणों को मर्ज करें:

    [hooks]
    exclude_commands = ["graft", "curl", "playwright"]

मौजूदा बहिष्करणों को संरक्षित करें और उनकी विचारणा सत्यापित करें।
यदि यह सेटिंग वैश्विक है, तो इसे संशोधित करने से पहले इस प्रभाव को सूचित करें।
दस्तावेज़ित तंत्र द्वारा वैकल्पिक टेलीमेट्री को अक्षम करें,
अनुमत स्कोप के भीतर।

RTK ही एकमात्र घटक है जिसे शेल कमांड्स को पुनर्लेखन करने की अनुमति है।
सुरक्षा, ऑडिट, और अनुमोदन हुक्स लागू रहते हैं।

दस्तावेज़ित संगतता के बिना Claude हुक को किसी अन्य क्लाइंट में कॉपी न करें।
प्रभावी पुनर्लेखन के बिना, स्पष्ट प्रिफिक्स `rtk` कॉन्फ़िगर करें।
डबल हुक्स और डबल प्रिफिक्स से बचें।

## 5. Graft with LSP

### स्थापना और गोपनीयता

पैकेज `@nanonets/graft` की पहचान, प्रकाशित संस्करण
और इसके Node आवश्यकताओं की जांच करें।

एप्लिकेशन निर्भरताओं के बाहर, उपयुक्त स्थान पर इंस्टॉल करें।
Graft इंस्टॉल करने के लिए package.json या परियोजना लॉकफ़ाइल को संशोधित न करें।

पहली लॉन्च और MCP में `DO_NOT_TRACK=1` लागू करें।
यदि उपलब्ध हो तो आधिकारिक टेलीमेट्री अक्षम कमांड का उपयोग करें।

Brain, खाता, LLM संवर्धन, या `--deep` को सक्रिय न करें।
बिना सत्यापित किए शून्य नेटवर्क का वादा न करें।

`graft init` को स्वचालित रूप से न चलाएं।
स्पष्ट वायरिंग को प्राथमिकता दें; इसका इंस्टॉलर रिपॉजिटरी के बाहर लिख सकता है।

### वास्तव में परिचालन LSP

एप्लिकेशन कोड का अन्वेषण करने से पहले, रिपॉजिटरी के Graft नियमों का सम्मान करें।
फिर उपयोगी भाषाओं की पहचान करें और चुने गए Graft संस्करण के
LSP इंटीग्रेशन देखें।

पहले से मौजूद संगत सर्वरों का पुन: उपयोग करें।
केवल आवश्यक सर्वरों को, रिकॉर्ड किए गए संस्करणों के साथ,
संभव हो तो एप्लिकेशन निर्भरताओं के बाहर इंस्टॉल करें।

जांचें:

- निष्पादन योग्य और उसका संस्करण;
- Graft/MCP प्रक्रिया के PATH में इसकी उपलब्धता;
- भाषा और कार्यक्षेत्र पूर्वापेक्षाएँ;
- इस Graft संस्करण द्वारा इसका समर्थन।

सहायता पढ़ने के बाद, यदि ये विकल्प उपलब्ध हों तो विशेष रूप से उपयोग करें:

    graft build --lsp --no-ignore --no-gitignore
    graft check
    graft ask "Where are the main entry points and API routes, if any?" --source

इन कमांड्स पर वर्तमान शेल सिंटैक्स के साथ DO_NOT_TRACK लागू करें।

विकल्पों का अर्थ जांचें: कुछ संस्करणों में,
`--no-ignore` और `--no-gitignore` बहिष्करण फ़ाइलें लिखने से रोकते हैं;
वे "अनदेखी की गई फ़ाइलों को इंडेक्स करें" का अर्थ नहीं रखते।

चुने गए स्कोप के अनुसार `/graft/` के Git बहिष्करण का स्पष्ट प्रबंधन करें।
Git से इसकी पुष्टि करें। पहले से ट्रैक की गई फ़ाइलों को स्वचालित रूप से न हटाएं।
टिप्पणियाँ और मानवीय सामग्री संरक्षित करें।

`--lsp` के साथ एक बिल्ड और 0 निकास कोड LSP उपयोग का प्रमाण नहीं है।
लक्षित प्रमाण खोजें: सर्वर वास्तव में लॉन्च हुआ, समाधान परिणाम,
संवर्धित एजेस या प्रलेखित डायग्नोस्टिक्स।

भाषा के अनुसार रिपोर्ट करें:
LSP सत्यापित / संवर्धन के बिना उपलब्ध / अनुपलब्ध / समर्थित नहीं।

संदर्भ में पूरे ग्राफ़ या wiring.json को कभी लोड न करें।
यह भी जांचें कि क्या LSP संवर्धन स्वचालित रिफ्रेश के बाद बना रहता है;
यदि गारंटी नहीं है, तो आवश्यक स्पष्ट पुनर्निर्माण को दस्तावेज़ित करें।

### MCP और ताजगी

प्रति क्लाइंट एकल प्रभावी Graft प्रविष्टि कॉन्फ़िगर करें।
वास्तव में समर्थित फ़ाइल, स्कीमा, और स्कोप खोजें।

प्रत्येक सर्वर के लिए सत्यापित करें:
इंस्टॉल किया गया कमांड, MCP तर्क, DO_NOT_TRACK, PATH, और कार्य निर्देशिका।

यह न मानें कि `.kimi-code/mcp.json`, `.mcp.json` या अन्य फ़ाइल स्वचालित रूप से लोड होती है: क्लाइंट तंत्र या आवश्यक लॉन्च विकल्प की पुष्टि करें।

एक वैश्विक MCP कॉन्फ़िगरेशन केवल तभी स्वीकार्य है जब लक्षित प्रक्रिया प्रत्येक रिपॉजिटरी को सही ढंग से संबोधित करे। अन्यथा, MCP को परियोजना स्तर पर रखें।

हर स्टार्टअप पर `npx -y ...@latest` का उपयोग न करें।
निजी पूर्ण पथ या रहस्यों को संस्करण नियंत्रण में न रखें।
सार्वभौमिक चर `${workspaceFolder}` का आविष्कार न करें।

इस प्रोफ़ाइल में कोई Graft हुक न जोड़ें।
कोई स्मार्ट-ग्रेप, ग्रेप-रिडायरेक्ट, या Graft शेल इंटरसेप्शन न करें।

रिफ्रेश और अनजाने में अक्षम होने की अनुपस्थिति की जांच करें।
एक विफल रिफ्रेश ग्राफ़ को ताजा के रूप में प्रस्तुत करने से रोकता है।

माइग्रेशन से पहले पुराने इंटीग्रेशन और ऑटो-वायरिंग मेटाडेटा का निरीक्षण करें।
केवल पहचाने गए और बैकअप किए गए तत्वों को हटाएं।
सुनिश्चित करें कि वे MCP स्टार्टअप और क्वेरी के बाद पुनः प्रकट न हों।

### Graft सांख्यिकी

अलग संचालन, देखी गई उपयोगिता, और सांख्यिकी संग्रह।

संस्करण के अनुसार, `graft stats` सेशन हुक्स पर निर्भर करता है।
इन हुक्स के बिना, "कोई सेशन अभी तक रिकॉर्ड नहीं हुआ" संदेश अपेक्षित हो सकता है, भले ही Graft अनुरोध सफल हों।

सांख्यिकी का निर्माण न करें या इस संदेश को हटाने के लिए `graft init` न चलाएं।

यदि उपयोगकर्ता को मूल सांख्यिकी की आवश्यकता है, तो उपलब्ध मापन हुक्स की संगतता प्रदर्शित करें और किसी भी सक्रियण से पहले हुक्स के बिना प्रोफ़ाइल विकास का स्पष्ट अनुरोध करें।

## 6. Ponytail lite

क्लाइंट और स्कोप के अनुकूल एक आधिकारिक एकीकरण को प्राथमिकता दें।
इसके मैनिफेस्ट, इवेंट्स, और निर्भरताओं की जांच करें।

भेद करें:
प्लगइन की स्थापना, सक्रियण, डिफ़ॉल्ट मोड, और वर्तमान मोड की स्थिति।

वास्तव में पढ़े गए स्रोतों का निरीक्षण करें:
कॉन्फ़िगरेशन, `PONYTAIL_DEFAULT_MODE`, स्थायी स्थिति, और प्लगइन डेटा।
`defaultMode: lite` यह साबित नहीं करता कि पुरानी पूर्ण स्थिति को प्रतिस्थापित किया गया था।

यदि मोड बातचीत के बीच साझा किया जाता है, तो इसे सूचित करें।
प्रोजेक्ट स्कोप में, वैश्विक डिफ़ॉल्ट को चुपचाप न बदलें।
दस्तावेजीकृत स्थानीय तंत्र या निर्देशों द्वारा lite नीति का उपयोग करें।

क्लाइंट के अनुसार:

- Claude/Codex: उपलब्ध स्कोप पर आधिकारिक स्थापना और सक्रियण।
  उपयोग से पहले सबकमांड्स की जांच करें।
  हुक अनुमोदन उपयोगकर्ता के पास रहता है।
- Cursor: आधिकारिक एडाप्टर, या निर्देश नियम; उनके संचय से बचें।
  यदि `scripts/cursor-hooks.js install --project` मौजूद है, तो स्क्रिप्ट को
  लक्ष्य रिपॉजिटरी की रूट से आधिकारिक चेकआउट पथ का उपयोग करके चलाएं।
  `--project` के बिना, उपयोगकर्ता गंतव्य की जांच करें।
  उत्पन्न पथों का निरीक्षण करें: एक प्रोजेक्ट हुक जिसमें व्यक्तिगत चेकआउट का पूर्ण पथ होता है
  वह पोर्टेबल नहीं है और इसे कमिट नहीं किया जाना चाहिए।
- Kimi: एक संगत आधिकारिक एडाप्टर खोजें। अन्यथा, AGENTS.md में lite नीति;
  केवल तभी एक न्यूनतम स्थानीय कौशल जोड़ें जब यह उपयोगी हो
  और यदि इसका प्रारूप और लोडिंग पुष्टि हो।
  इसे एक अनुकूलन के रूप में पहचानें, बिना मूल कमांड या सांख्यिकी का वादा किए।
- अन्य चयनित क्लाइंट्स: समान सत्यापन लागू करें, बिना स्वचालित रूप से
  Claude/Codex इवेंट्स को स्थानांतरित किए।

एडाप्टर चेकआउट को पहचाने गए संस्करण या कमिट पर रखें।
संशोधित चेकआउट पर git pull न करें।
स्टेटसलाइन या दृश्य संकेतक न जोड़ें।

नई सेशन में प्रभावी मोड का परीक्षण करें।

## 7. Compact common instructions

एक ब्लॉक को मर्ज करें जो निम्नलिखित से सीमांकित हो:

    <!-- agent-stack:start -->
    ...
    <!-- agent-stack:end -->

AGENTS.md में। सभी बाहरी सामग्री और मानव द्वारा जोड़े गए हिस्सों को बनाए रखें।
इस स्थापना प्रॉम्प्ट को एजेंट निर्देशों में कॉपी न करें।

ब्लॉक को निम्नलिखित व्यक्त करना चाहिए:

### Graft

कोड को समझने या संशोधित करने के लिए, पहले एप्लिकेशन अन्वेषण:
`graft ask "<precise question>" --source`, या वास्तव में प्रदर्शित MCP Graft टूल।

निर्देश, कौशल, Git, कॉन्फ़िगरेशन, और MCP खोज पहले हो सकते हैं।
दिशा-निर्देशन के बाद, सीधे उपयोगी हिस्सों को पढ़ें।
कॉलर के लिए, उपलब्ध ट्रेस कमांड/टूल्स का उपयोग करें।

पुराने ग्राफ के मामले में: जांचें, LSP के साथ अनुकूलित पुनर्निर्माण, फिर नया क्वेरी।
असफल खोज के बाद: लक्षित graft grep, फिर सीधे पढ़ना
या सीमा के स्पष्टीकरण के साथ सीमित rg।

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

संशोधनों के बाद: graft blast, सत्यापित Git बेस, और संबंधित परीक्षण।
कोई --name नहीं, कोई पूर्ण ग्राफ लोडिंग नहीं।
वास्तविक कॉल की संख्या और किसी भी त्रुटि की रिपोर्ट करें।

### RTK

सत्यापित हुक: पुनर्लेखन को डबल प्रीफिक्स के बिना कार्य करने दें।
अन्यथा: संगत कमांड्स को स्पष्ट रूप से प्रीफिक्स करें।
Graft को RTK के माध्यम से कभी न पास करें।

पूर्ण आउटपुट के लिए: यदि उपलब्ध हो तो --full याद करें, या प्रॉक्सी।
साइड इफेक्ट्स वाले कमांड को स्वचालित रूप से पुनः न चलाएं।
पाइपलाइंस और रीडायरेक्शंस को बनाए रखें।

मान्यता से पहले: वास्तविक अनकंप्रेस्ड डिफ्स, diff --cached,
diff --check और नई फ़ाइलों का अलग निरीक्षण।
कोई स्वचालित स्टेजिंग नहीं।

### Ponytail lite

अनुरोध को सही ढंग से लागू करें और मौजूदा का पुन: उपयोग करें।
एक महत्वपूर्ण रूप से सरल समाधान की संक्षिप्त रिपोर्ट करें।
मान्यता, सुरक्षा, अनुमतियाँ, पहुंच, लेनदेन
और आवश्यक परीक्षणों को बनाए रखें। हटाने या इनलाइन करने से पहले उपयोगों की जांच करें।

केवल स्पष्ट अनुरोध पर पूर्ण, डिफ़ॉल्ट रूप से कभी भी अल्ट्रा नहीं।
एक ऑडिट पुनः डिज़ाइन को ट्रिगर नहीं करता।
सुरक्षा, पार्सर्स, समवर्तीता, और माइग्रेशन के लिए सुधार प्राथमिकता लेता है।

कभी न दावा करें कि साझा मोड बातचीत के लिए स्थानीय है।
एक अधिकृत पूर्ण के बाद, lite पर वापसी की पुष्टि करें।
ऑफ पहले से इंजेक्ट किए गए निर्देशों को नहीं हटाता।

### Loading

प्रत्येक क्लाइंट वास्तव में इन निर्देशों को कैसे लोड करता है, इसकी पुष्टि करें।
दस्तावेजीकृत न्यूनतम इम्पोर्ट/एडाप्टर का उपयोग करें।
डुप्लिकेशन और सर्कुलर इम्पोर्ट से बचें।

RTK ही एकमात्र शेल पुनर्लेखक है।
इस प्रोफ़ाइल में कोई Graft हुक नहीं।

## 8. Update and Repair

एक ही प्रॉम्प्ट को बिना डुप्लिकेट के पुनः चलाया जा सके।

अपडेट मोड में:

1. स्कोप विकल्पों और पहले सत्यापित स्थिति को पुनः पढ़ें।
2. स्थापित संस्करणों, लक्ष्य संस्करणों, और असंगत परिवर्तनों की तुलना करें।
3. किसी भी माइग्रेशन से पहले बैकअप लें।
4. केवल चयनित घटकों को अपडेट करें।
5. आधिकारिक तंत्र के साथ प्लगइन्स/एडाप्टर को ताज़ा करें।
6. क्षमताओं का पुनर्मूल्यांकन करें: एक पुराना फॉलबैक अब उपलब्ध मूल एकीकरण द्वारा प्रतिस्थापित किया जा सकता है, उसी स्कोप के भीतर।
7. केवल इस स्टैक से संबंधित कुंजी और ब्लॉकों को माइग्रेट करें।
8. आवश्यक होने पर ग्राफ को पुनर्निर्मित करें और LSP की पुनः जांच करें।
9. आवश्यक MCP/क्लाइंट प्रक्रियाओं को पुनः प्रारंभ करें:
   एक मौजूदा प्रक्रिया अभी भी पुराना संस्करण चला सकती है।
10. संशोधित एकीकरणों के चेक और परीक्षणों को पुनः चलाएं।

पहले से अनुपालन वाले घटक को अनावश्यक रूप से पुनः स्थापित न करें।
मशीन के पैकेजों का सामान्य अपडेट न चलाएं।

मरम्मत मोड में, संस्करणों को बनाए रखें सिवाय प्रदर्शित असंगतता
और स्पष्ट अपडेट निर्णय के।

लक्षित रोलबैक तैयार करें: पिछले संस्करण, बैकअप,
और सटीक कमांड। यदि बैकअप के बाद अन्य परिवर्तन हुए हैं तो पूरी फ़ाइल को अंधाधुंध पुनर्स्थापित न करें।

अनुरोधित परिवर्तनों के बिना दूसरी बार निष्पादन किसी भी हुक, MCP सर्वर, या डुप्लिकेट निर्देश अनुभाग को नहीं बनाना चाहिए।

## 9. Checks and Evidence

अलग से परीक्षण करें:

- RTK निष्पादन योग्य और स्पष्ट संपीड़न;
- स्वचालित हुक ट्रिगरिंग, बहिष्करण, और कच्चा पास-थ्रू;
- Graft: ताजगी, रिपॉजिटरी से मेल खाने वाला परिणाम, और LSP समृद्धि;
- MCP: कार्यात्मक सर्वर और प्रत्येक क्लाइंट में वास्तविक लोडिंग;
- Ponytail: सक्रियण और प्रभावी मोड;
- डुप्लिकेट की अनुपस्थिति और पुनः प्रकट हुई सेल्फ-वायरिंग;
- विन्यासों की अंतिम वैधता और प्रभावी दायरा।

एक वर्तमान फ़ाइल लोडिंग का प्रमाण नहीं है।
एक बाहरी MCP जांच क्लाइंट में लोडिंग का प्रमाण नहीं है।
एक स्पष्ट RTK उपसर्ग स्वचालित हुक का प्रमाण नहीं है।

प्रत्येक उपलब्ध और प्रमाणित क्लाइंट के लिए, रिपॉजिटरी में एक नया सत्र खोलें,
इसके सामान्य सुरक्षा उपायों के साथ, और यह तटस्थ टिकट दें:

"कोड को संशोधित किए बिना, मुख्य प्रवेश बिंदुओं का पता लगाएं।
यदि कोई API है, तो बताएं कि इसके रूट्स कहाँ माउंट किए गए हैं और
बिजनेस लॉजिक तक एक पथ ट्रेस करें। फ़ाइलें और पंक्तियाँ उद्धृत करें।"

"use Graft" न जोड़ें।
दृश्य टूल कॉल्स का निरीक्षण करें, आंतरिक तर्क नहीं।
न्यूनतम साक्ष्य रखें और संवेदनशील डेटा को छिपाएं।

यदि अनुमोदन, लॉगिन, या UI क्रिया गायब है:
परीक्षण नहीं किया गया / उपयोगकर्ता क्रिया, सफलता कभी भी मान्य न करें।

## 10. डिलीवेरेबल

अधिकृत दायरे के भीतर, एक संक्षिप्त रखरखाव दस्तावेज़ीकरण रखें:

- संचालन विकल्प, क्लाइंट, और दायरा;
- सटीक संस्करण, स्रोत, और सत्यापन तिथि;
- विन्यास तंत्र और सीमाएँ;
- Graft/LSP पुनर्निर्माण;
- अपडेट, सत्यापन, और रोलबैक प्रक्रिया।

साझा स्थापना के लिए, `docs/agent-stack.md` का उपयोग करें।
व्यक्तिगत/वैश्विक स्थापना के लिए, मशीन-विशिष्ट जानकारी को संस्करणित फ़ाइलों से बाहर रखें।
केवल सत्यापन मोड में, ये फ़ाइलें बनाए बिना रिपोर्ट दें।

निर्णायक कमांड, उनके परिणाम, संशोधित फ़ाइलें,
बैकअप, और सटीक उपयोगकर्ता क्रियाओं की रिपोर्ट करें।

अंतिम हुक्स का सूची बनाएं:
क्लाइंट, स्रोत, दायरा, घटना, मैचर, भूमिका, और छिपाया गया कमांड।

इससे समाप्त करें:

Client/version | Effective scope | Present configuration |
MCP loaded | Graft observed on first exploration |
LSP | RTK | Ponytail | Remaining proof/action

स्पष्ट अवस्थाएँ उपयोग करें:
CONFIGURED / LOADED / USAGE OBSERVED / NOT TESTED / BLOCKED / NOT APPLICABLE।

फ़ाइलों को वर्गीकृत करें:
REVIEW के बाद कमिट करने के लिए / अनदेखा करने के लिए / मशीन कॉन्फ़िगरेशन।

व्यक्तिगत पथ, रहस्य, कैश, ग्राफ, बैकअप, और ट्रांसक्रिप्ट
कमिट करने वाली फ़ाइलों में शामिल नहीं होने चाहिए।

अंतिम Git स्थिति और इस हस्तक्षेप द्वारा किए गए परिवर्तनों को प्रदर्शित करें,
इन्हें पूर्व-मौजूद परिवर्तनों से अलग करते हुए। कुछ भी कमिट न करें।

टैग