2026 में हर किसी के लिए जरूरी AI एजेंट मेमोरी स्टैक (बिल्डर्स गाइड)

आपका मॉडल और हार्नेस अब मायने नहीं रखते।

अब जो ज़्यादा मायने रखता है वो है.....

आपका व्यक्तिगत संदर्भ/साझा मेमोरी

परिचय

मैं आपको दिखाने जा रहा हूँ कि अपने कोडिंग एजेंटों के लिए एक साझा मेमोरी कैसे बनाई जाए... ताकि अगला टूल आपके द्वारा पहले से लिए गए निर्णयों को ढूंढ सके।

Claude में आर्किटेक्चर चर्चा, Codex में डिबगिंग सेशन, Cursor में दबी हुई व्याख्या... उपयोगी काम जो अब भी उपलब्ध होना चाहिए जब आप टूल बदलते हैं, कोई दूसरा सेशन शुरू करते हैं, या एक महीने बाद प्रोजेक्ट पर वापस आते हैं।

TLDR; यदि आप सभी 3,845 शब्द नहीं पढ़ना चाहते हैं तो बस यह GitHub रिपॉजिटरी अपने एजेंट को दें ➡️ https://github.com/codejunkie99/agentic-stack-desktop

मैंने यह पूरी चीज़ Codex Harness में Kimi K3 का उपयोग करके बनाई है। वीडियो Kimi K3 को Cua for Computer Use के साथ उपयोग करके बनाया और संपादित किया गया था।

यह Agentic Stack Desktop के लिए एक बिल्डर गाइड है, आपके पहले इम्पोर्ट से लेकर एक ऐसे वर्कफ़्लो तक जहाँ एक एजेंट पिछले निर्णय को पुनर्प्राप्त कर सकता है, उसे वर्तमान कोड के विरुद्ध जाँच सकता है, एक सीमित बदलाव कर सकता है, और पीछे कुछ उपयोगी छोड़ सकता है।

यहाँ बताया गया है कि आपको क्या मिल रहा है:

1. आधार: जब आप टूल स्विच करते हैं तो क्या बचता है
2. सबसे तेज़ रास्ता: एक ऐसा वर्कस्पेस बनाएं जिसका आप मूल्यांकन कर सकें
3. कार्यशील सेटअप: जाँच को कार्यान्वयन से अलग करें
4. प्रोजेक्ट अभ्यास: एक बार-बार आने वाले बग को पूरे चक्र से गुज़ारें
5. साझा परत: अपने अन्य टूल में पुनर्प्राप्ति लाएं
6. टिकाऊ परत: क्या एक सबक बनने लायक है
7. संचालन नियम: संक्षिप्त, सीमित, निरीक्षण योग्य
8. कस्टम बिल्ड: एक वास्तविक समस्या बिंदु के आसपास वर्कस्पेस बदलें
9. स्केलिंग: कवरेज जोड़ें जहाँ पिछले चक्र ने एक अंतर उजागर किया
10. बिल्ड शीट

1. आधार: जब आप टूल स्विच करते हैं तो क्या बचता है

कल्पना करें कि आपने एक दोपहर यह तय करने में बिताई कि एक फीचर को कैसे काम करना चाहिए। आपने विकल्पों का पता लगाया, एक बाधा पाई, स्पष्ट समाधान को अस्वीकार किया, और अंततः कुछ ऐसा पाया जो फिट बैठता है।

कार्यान्वयन कमिट हो जाता है। स्पष्टीकरण बातचीत में ही रह जाता है।

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

तर्क को पुनर्प्राप्त करने योग्य बनाएं

यहाँ से शुरू करें: उस चर्चा को पुनर्प्राप्त करने योग्य बनाएं, फिर अगले एजेंट को कार्रवाई करने से पहले उसे जाँचने के लिए कहें।

Agentic Stack Claude Code, Codex, OpenCode और Cursor से खोजने योग्य, चयनित इतिहास के साथ एक मूल macOS वर्कस्पेस प्रदान करता है। Claude Code और Codex अपने आधिकारिक CLI के माध्यम से भी निष्पादित होते हैं; Cursor और OpenCode वर्तमान में केवल संदर्भ प्रदान करते हैं। रिपॉजिटरी अवलोकन

नीचे दिया गया वर्कफ़्लो वह है जिसका उपयोग मैं उन क्षमताओं के लिए करूँगा। ब्रीफ़, जिम्मेदारियों का विभाजन और प्रोजेक्ट अभ्यास सुझाए गए संचालन अभ्यास हैं जिन्हें आप अनुकूलित कर सकते हैं।

2. सबसे तेज़ रास्ता: एक ऐसा वर्कस्पेस बनाएं जिसका आप मूल्यांकन कर सकें

एक ऐसी रिपॉजिटरी से शुरू करें जिसे आप समझते हैं। कुछ ऐसा चुनें जहाँ आप महत्वपूर्ण फ़ाइलों को जानते हों, एक हालिया निर्णय याद हो, और एक खराब सिफारिश को पहचान सकें।

एक परिचित प्रोजेक्ट आपको एक संदर्भ बिंदु देता है। यदि आप अपरिचित कोड और अपरिचित इतिहास से शुरू करते हैं, तो आप एक साथ टूल को मान्य करने और सिस्टम को सीखने की कोशिश कर रहे होंगे।

स्रोत बिल्ड के लिए, दस्तावेज़ित आवश्यकताओं में macOS 14+, Python 3.10+, Xcode Command Line Tools और Swift 6 टूलचेन शामिल हैं। इंस्टॉल करें और उस कोडिंग CLI में साइन इन करें जिसे आप चलाना चाहते हैं। आवश्यकताएँ

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

अपनी रिपॉजिटरी को ऐप में खोलें और गाइडेड सेटअप पूरा करें। यह एडहॉक साइनिंग के साथ एक प्रीव्यू है, इसलिए पहले लॉन्च पर macOS को पुष्टि की आवश्यकता हो सकती है। सेटअप

पहली स्वीकृति जाँच सेट करें

कुछ भी इम्पोर्ट करने से पहले, वह प्रश्न लिखें जिसका उत्तर आप पहले एजेंट से चाहते हैं। कुछ इस तरह: हमारा एक्सपोर्ट जॉब रिकॉर्ड को बैचों में क्यों प्रोसेस करता है, और क्या वर्तमान कार्यान्वयन को अभी भी उस सीमा की आवश्यकता है?

वह प्रश्न आपकी पहली स्वीकृति जाँच बन जाता है। आप सही निर्णय, सही सहायक कोड, और जो कुछ भी एजेंट स्थापित नहीं कर सकता है उसकी एक ईमानदार व्याख्या की तलाश कर रहे हैं।

2.1 पहला इम्पोर्ट: इसे एक खोजने लायक निर्णय दें

नॉलेज ग्राफ → ग्राफ़ → इम्पोर्ट मेमोरी खोलें, स्रोतों का पूर्वावलोकन करें, और वह सामग्री चुनें जिसे आप शामिल करना चाहते हैं।

ग्राफ़ SQLite फ़ुल-टेक्स्ट सर्च का उपयोग करता है, जिसमें विषयों, रिपॉजिटरी लिंक और उत्पत्ति के आधार पर कनेक्शन होते हैं; मूल चैट स्टोर अपरिवर्तित रहते हैं। इम्पोर्ट व्यवहार

मैं एक पूर्ण वार्तालाप से शुरुआत करूँगा जिसमें आपको याद किया गया कोई निर्णय हो। विशेष रूप से वह जहाँ आपने एक बाधा के कारण कुछ आकर्षक अस्वीकार कर दिया था जो अंतिम कोड से स्पष्ट नहीं होता।

इम्पोर्ट के बाद उस निर्णय को खोजें। परिणाम खोलें और स्रोत का निरीक्षण करें। सुनिश्चित करें कि आप उस वार्तालाप को देख रहे हैं जिसे आप लाना चाहते थे, जिसमें यह समझने के लिए पर्याप्त व्याख्या हो कि क्या हुआ।

परीक्षण करें कि क्या आप इसे फिर से पा सकते हैं

फिर उस शब्दावली का उपयोग करके दूसरी खोज का प्रयास करें जिसका आप अगले महीने स्वाभाविक रूप से उपयोग करेंगे। हो सकता है कि आपको फीचर का नाम याद हो जबकि वार्तालाप में एक आंतरिक मॉड्यूल नाम का उपयोग किया गया हो। उस बेमेल को अब खोजने से आपको यह समझने में मदद मिलती है कि बाद में सामग्री को कैसे पुनर्प्राप्त किया जाए।

मैं पहले संग्रह को मैन्युअल रूप से निरीक्षण करने के लिए पर्याप्त छोटा रखूंगा। किसी ज्ञात स्रोत से सही उत्तर इस बात का उपयोगी प्रमाण है कि वर्कफ़्लो काम करता है।

एक बड़ी इम्पोर्ट संख्या आपको बताती है कि सिस्टम में कितनी सामग्री दर्ज हुई, जबकि इसकी उपयोगिता का परीक्षण किया जाना बाकी है।

संग्रह का विस्तार तब करें जब कोई अन्य कार्य आपको इसका कारण दे।

2.2 पहला कार्य सत्र: प्रयोग को इतना छोटा बनाएं कि वह पूरा हो सके

मैं प्रारंभिक सेटअप को कोई अन्य कॉन्फ़िगरेशन स्क्रीन खोलने से पहले एक समाप्ति रेखा दूंगा। सत्र के अंत तक, आपको एक ज्ञात निर्णय पुनर्प्राप्त कर लेना चाहिए, उसे रिपॉजिटरी के विरुद्ध जाँच लेना चाहिए, और एक समीक्षा तैयार कर लेनी चाहिए जिसे आप किसी और को समझा सकें।

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

अभ्यास के बगल में एक छोटा नोट रखें: प्रश्न, अपेक्षित स्रोत, वर्तमान कार्यान्वयन, और वह भाग जिसमें निर्णय की आवश्यकता है। उत्तर का मूल्यांकन करने के लिए यह आपका संदर्भ है।

सही विफलता का निदान करें

• यदि समीक्षक गलत वार्तालाप पुनर्प्राप्त करता है, तो पुनर्प्राप्ति पर काम करें।
• यदि वह सही वार्तालाप ढूंढता है लेकिन कोड को गलत पढ़ता है, तो जाँच पर काम करें।
• यदि निष्कर्ष सही हैं लेकिन कार्यान्वयन आवश्यकता को पूरा नहीं करता है, तो हैंडऑफ़ में सुधार करें।

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

सबसे छोटा पूरा चक्र समाप्त करें, रिकॉर्ड करें कि क्या विफल रहा, और अगले सुधार को चुनने के लिए उस साक्ष्य का उपयोग करें।

3. कार्यशील सेटअप: जाँच को कार्यान्वयन से अलग करें

मेरे सुझाए गए पहले सेटअप में एक केवल-पढ़ने योग्य समीक्षक और प्रोजेक्ट संपादन पहुँच वाला एक कार्यान्वयनकर्ता है। प्रत्येक को एक स्पष्ट डिलिवरेबल दें, और हैंडऑफ़ को ऐसा बनाएं जिसे आप किसी भी बदलाव से पहले पढ़ सकें।

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

1. एजेंट 1: समीक्षक को पहला प्रश्न मिलता है: हमने क्या तय किया, कोड अब क्या करता है, और क्या कोई अंतर है जिसे संबोधित करना उचित है?
2. एजेंट 2: कार्यान्वयनकर्ता को समीक्षित उत्तर और एक सीमित अनुरोध मिलता है: यह व्यवहार परिवर्तन करें, इस दायरे में, और इसे इस तरह सत्यापित करें।

भूमिकाओं को अलग रखें

आप दोनों भूमिकाओं के लिए एक ही रनर चुन सकते हैं।

उपयोगी अंतर उनकी जिम्मेदारी और पहुँच में है, जाँच और संपादन के बीच एक स्पष्ट समीक्षा के साथ।

मैं किसी भी विशेषज्ञ की सूची बनाने से बचूंगा जब तक कि उनमें से किसी ने उपयोगी काम पूरा नहीं कर लिया हो। उन जिम्मेदारियों से शुरू करें जिन्हें आप वास्तव में अलग कर सकते हैं। यदि आप यह नहीं समझा सकते कि एक भूमिका के पास क्या है या उसका तैयार आउटपुट कैसा दिखता है, तो कोई और एजेंट जोड़ने से पहले भूमिका को कस लें।

3.1 समीक्षक: एक ब्रीफ़ जो अनिश्चितता को दृश्यमान बनाती है

समीक्षक का चयन करें और @Claude, @Codex, @OpenCode या @Cursor का उपयोग करके प्रासंगिक वार्तालाप संलग्न करें। चयनित संदर्भ रन के लिए जमे हुए संदर्भ बन जाते हैं और कार्य शुरू होने पर चुने गए एजेंट के पास जाते हैं। संदर्भ

इस ब्रीफ़ को कॉपी करें और स्लॉट भरें:

1संलग्न वार्तालाप और वर्तमान रिपॉजिटरी का उपयोग करके [फीचर या सबसिस्टम] के बारे में पिछले निर्णय की समीक्षा करें।
2
3मूल निर्णय और उसके बताए गए कारण की व्याख्या करें। प्रासंगिक कोड की जाँच करें और पहचानें कि अब भी क्या लागू होता है, क्या बदला है, और उपलब्ध साक्ष्य से क्या सत्यापित नहीं किया जा सकता है।
4
5अपने निष्कर्षों का समर्थन करने वाली फ़ाइलों का हवाला दें। [वांछित व्यवहार] के लिए आवश्यक सबसे छोटे बदलाव का प्रस्ताव करें, एक सत्यापन योजना के साथ।
6
7फ़ाइलों में संपादन न करें। वार्तालाप को ऐतिहासिक साक्ष्य के रूप में मानें और वर्तमान प्रोजेक्ट निर्देशों के साथ विरोधों को चिह्नित करें।

समीक्षा का निरीक्षण करें

रिपॉजिटरी को खुला रखकर उत्तर पढ़ें।

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

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

एक उपयोगी जाँच लापता साक्ष्य के साथ समाप्त हो सकती है। यह आपको बताता है कि आगे क्या आपूर्ति करनी है। एक उत्तर जो अंतर को चिकना कर देता है, अगले निर्णय को और कठिन बना देता है।

3.2 हैंडऑफ़: निष्कर्षों को एक निष्पादन योग्य ब्रीफ़ में बदलें

एक बार जब आप समीक्षा से सहमत हो जाते हैं, तो कार्यान्वयन अनुरोध को देखने योग्य व्यवहार के आसपास लिखें। पिछली वार्तालाप द्वारा स्थापित बाधा को शामिल करें, लेकिन इस बदलाव के लिए इसकी प्रासंगिकता स्पष्ट करें।

यहाँ एक ब्रीफ़ है जिसका मैं उपयोग करूंगा:

1नीचे दिए गए समीक्षित निष्कर्षों का उपयोग करके [विशिष्ट व्यवहार] लागू करें।
2
3[मौजूदा व्यवहार] को बरकरार रखें। संपादनों को [अनुमत दायरे] तक सीमित करें। यदि बदलाव के लिए उस दायरे के बाहर काम करने की आवश्यकता है, तो विस्तार करने से पहले कारण बताएं।
4
5संपादन से पहले वर्तमान रिपॉजिटरी निर्देशों की जाँच करें। [प्रासंगिक परीक्षण या मैन्युअल जाँच] के साथ [अपेक्षित परिणाम] सत्यापित करें, जिसमें [महत्वपूर्ण विफलता मामला] शामिल है।
6
7क्या बदला, वास्तव में चलाई गई जाँचें, और कोई भी अनसुलझी सीमा का संक्षिप्त विवरण लौटाएँ। प्रकाशित या डिप्लॉय न करें।
8
9समीक्षित निष्कर्ष:
10[वे निष्कर्ष चिपकाएँ जिनकी आपने जाँच की]

हैंडऑफ़ को विशिष्ट बनाएं

वे कोष्ठक वास्तविक उत्तरों के लायक हैं। "इसे बेहतर बनाएं" एजेंट को लक्ष्य का आविष्कार करने के लिए छोड़ देता है। "मूल त्रुटि को संरक्षित करते हुए एक रीट्राई एक्शन के साथ विफल एक्सपोर्ट दिखाएं" आप दोनों को निरीक्षण करने के लिए कुछ ठोस देता है।

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

स्रोत बताता है कि बाधा कहाँ से आई। आपका वर्तमान अनुरोध बताता है कि यह आज के काम को कैसे नियंत्रित करता है।

4. प्रोजेक्ट अभ्यास: एक बार-बार आने वाले बग को पूरे चक्र से गुज़ारें

यहाँ वर्कफ़्लो को ठोस बनाने के लिए एक काल्पनिक अभ्यास है। कल्पना करें कि आपका प्रोजेक्ट कभी-कभी नेटवर्क रुकावट के बाद डुप्लिकेट एक्सपोर्ट बनाता है, और एक पुरानी वार्तालाप में रीट्राई व्यवहार की जाँच है।

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

यह उदाहरण एक प्रस्तावित अभ्यास है, न कि Agentic Stack में बग का दावा। अपने स्वयं के प्रोजेक्ट से एक वास्तविक विफलता को प्रतिस्थापित करें और उसी अनुक्रम को बनाए रखें।

5. साझा परत: अपने अन्य टूल में पुनर्प्राप्ति लाएं

डेस्कटॉप टूल्स → कनेक्शन → टूल में @ का उपयोग करें → सभी चार टूल में सक्षम करें के माध्यम से एकीकरण स्थापित कर सकता है। कमांड समकक्ष है:

1agentic-stack context install

बाद में टूल को पुनरारंभ करें। MCP प्रविष्टि वार्तालाप खोज, चयनित-चैट रीडिंग और साझा-मेमोरी खोज को उजागर करती है। एकीकरण

पिकर व्यवहार क्लाइंट पर निर्भर करता है; जहाँ संसाधन पूर्णता उपलब्ध नहीं है, एजेंट मिलान वार्तालापों को खोज और प्रस्तुत कर सकता है। क्लाइंट व्यवहार

टूल में निरंतरता का परीक्षण करें

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

फिर परिणाम की तुलना उस स्रोत से करें जिसका आपने डेस्कटॉप में निरीक्षण किया था। आप टूल में संदर्भ की निरंतरता का परीक्षण कर रहे हैं, इसलिए जिस स्थान पर आप प्रश्न पूछते हैं उसे बदलते हुए प्रश्न को स्थिर रखें।

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

6. टिकाऊ परत: क्या एक सबक बनने लायक है

पुनर्प्राप्ति पुरानी सामग्री को वापस दृश्य में लाती है। आपको अभी भी यह तय करना है कि उस सामग्री को कितना अधिकार देना चाहिए।

एक वार्तालाप में एक परित्यक्त योजना, एक गलत निदान, या एक उत्तर हो सकता है जो प्रोजेक्ट के बदलने से पहले उचित था। इसे संरक्षित करने से आप बाद में तर्क का निरीक्षण कर सकते हैं; एक सबक स्वीकार करना एक अलग निर्णय है।

कार्य निष्पादन रिकॉर्ड रखता है। नॉलेज → लेसन्स कारणों के साथ सबक को स्टेज करने, स्वीकार करने, अस्वीकार करने और पुनर्विचार करने का समर्थन करता है, जबकि इम्पोर्ट किया गया इतिहास स्वीकृत सबक से अलग रहता है। समीक्षा जीवनचक्र

एक ऐसा सबक लिखें जिसे चुनौती दी जा सके

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

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

फिर पूछें कि सबक को अप्रचलित क्या बनाएगा। एक अलग बैकएंड, एक बदला हुआ अनुबंध, या एक बदला हुआ सबसिस्टम मूल बाधा को हटा सकता है। उस सीमा को शामिल करें ताकि भविष्य की समीक्षा को शुरू करने के लिए कोई जगह मिले।

इस तरह मैं एक उपयोगी सुधार को एक ऐसे नियम में बदलने से रोकूंगा जो अपने कारण से अधिक जीवित रहता है।

6.1 मेमोरी संरचना: प्रत्येक प्रकार के ज्ञान को उसके स्थान पर रखें

डेस्कटॉप के नीचे, पोर्टेबल .agent/ आर्किटेक्चर कार्यशील स्थिति, पिछले एपिसोड, टिकाऊ पैटर्न और व्यक्तिगत प्राथमिकताओं को अलग करता है। स्किल्स पुन: प्रयोज्य प्रक्रियाएँ प्रदान करते हैं, जबकि प्रोटोकॉल अनुमतियों और प्रतिनिधिमंडल का वर्णन करते हैं। आर्किटेक्चर

• वर्तमान जाँच प्रगति पर काम से संबंधित है।
• इसका पूरा विवरण इस बात का साक्ष्य बन जाता है कि क्या हुआ।
• एक सत्यापित पैटर्न एक टिकाऊ सबक बन सकता है।
• आप परिणाम कैसे प्रस्तुत करना चाहते हैं, इसके बारे में एक प्राथमिकता आपकी प्राथमिकताओं से संबंधित है।

उन अर्थों को स्पष्ट रखने से बाद की समीक्षा आसान हो जाती है। एक अस्थायी वर्कअराउंड को यह समझाना चाहिए कि इसे कब हटाया जा सकता है। एक व्यक्तिगत लेखन प्राथमिकता को गलती से एक आर्किटेक्चरल नियम नहीं बनना चाहिए।

एक सत्यापित प्रक्रिया को स्किल में बदलें

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

एक्सपोर्ट उदाहरण के लिए, जाँच एक उपयोगी रिग्रेशन-जाँच प्रक्रिया उत्पन्न कर सकती है। इसे तभी सहेजें जब आपने पुष्टि कर ली हो कि चरण आपके प्रोजेक्ट पर काम करते हैं। एक कॉपी किया गया ट्रांसक्रिप्ट अगले एजेंट को एक कहानी देता है; एक समीक्षित प्रक्रिया इसे एक ऐसी विधि देती है जिसका आप मूल्यांकन कर सकते हैं।

7. संचालन नियम: संक्षिप्त, सीमित, निरीक्षण योग्य

यहाँ वे नियम हैं जिन्हें मैं पहले प्रोजेक्ट से वर्कफ़्लो के आसपास रखूंगा।

1. नियम 1: प्रत्येक ब्रीफ़ डिलिवरेबल का नाम बताती है। एक समीक्षा साक्ष्य के साथ निष्कर्ष लौटाती है। एक कार्यान्वयन जाँच के साथ एक व्यवहार परिवर्तन लौटाता है। एक सबक प्रस्ताव एक दावा लौटाता है जिसे आप स्वीकार या अस्वीकार कर सकते हैं।
2. नियम 2: पहुँच कार्य का अनुसरण करती है। जाँच केवल-पढ़ने की पहुँच से शुरू होती है; कार्यान्वयन को सहमत बदलाव के लिए आवश्यक दायरा मिलता है। प्रकाशन, डिप्लॉयमेंट और अन्य परिणामी कार्यों को अनुरोध में स्पष्ट रखें।
3. नियम 3: वास्तविक सत्यापन माँगें। रिपोर्ट में कहा जाना चाहिए कि क्या चला और क्या हुआ। यदि कोई जाँच उपलब्ध नहीं थी, तो उसे दृश्यमान बनाएं बजाय चुपचाप लापता परिणाम को सफलता मानने के।
4. नियम 4: ऐतिहासिक संदर्भ को वर्तमान साक्ष्य और लागू प्रोजेक्ट निर्देशों के अधीन रखें। एक पुनर्प्राप्त वार्तालाप पिछले निर्णय की व्याख्या कर सकता है जबकि फिर भी पुराना हो सकता है।
5. नियम 5: निष्कर्ष को बनाए रखने से पहले परिणाम की समीक्षा करें। एक एजेंट का अपने काम के बारे में स्पष्टीकरण कुछ ऐसा है जिसका निरीक्षण डिफ़ और देखे गए व्यवहार के साथ किया जाना चाहिए।

ये उस सेटअप के लिए संचालन अभ्यास हैं जिसका मैं वर्णन कर रहा हूँ। उन्हें अपने प्रोजेक्ट में समायोजित करें, लेकिन जिम्मेदारियों को इतना स्पष्ट रखें कि कोई अन्य व्यक्ति बता सके कि किसी कार्य ने अपनी ब्रीफ़ पूरी की या नहीं।

7.1 समीक्षा कतार: काम को स्वीकार करना या वापस भेजना आसान बनाएं

मैं प्रत्येक कार्यान्वयन को एक ही आकार में समाप्त करने के लिए कहूंगा:

• क्या बदला,
• क्या सत्यापित किया गया,
• क्या अनिश्चित बना हुआ है,
• और क्या यह एक पुन: प्रयोज्य सबक प्रस्तावित करता है।

यह आपको हर बार पूरी वार्तालाप का पुनर्निर्माण किए बिना पूर्ण किए गए कार्य को पढ़ने का एक सुसंगत तरीका देता है। सहायक विवरण उस भाग के लिए उपलब्ध रह सकता है जिसका आपको निरीक्षण करने की आवश्यकता है।

जब आप कुछ वापस भेजते हैं, तो सुधार को उस आवश्यकता से संलग्न करें जिसे वह चूक गया। "यह गलत है" एक और अनुमान लगाने का चक्र शुरू करता है। "रीट्राई इस शर्त के तहत दूसरा एक्सपोर्ट बनाता है; मूल अनुरोध पहचान को संरक्षित करें और इस जाँच को फिर से चलाएँ" अंतर की पहचान करता है।

तय करें कि क्या बचने लायक है

सुधार पास होने के बाद, तय करें कि क्या यह एक आवर्ती बाधा का प्रतिनिधित्व करता है या उस कार्य का एक विवरण। पूर्व को तब सहेजें जब उसके पीछे साक्ष्य हो। बाद वाला कार्य के इतिहास में रह सकता है।

मैं हर समीक्षा टिप्पणी को स्थायी मेमोरी में बदलने का विरोध करूंगा। कुछ सुधार एक बार उपयोगी होते हैं। अन्य एक ऐसा नियम प्रकट करते हैं जो बाद के काम को आकार देना चाहिए। यह अंतर करना सिस्टम को बनाए रखने का हिस्सा है।

समीक्षा के अंत में उपयोगी प्रश्न यह है: एक भविष्य के एजेंट को एक समान कार्य शुरू करने से पहले क्या पता होना चाहिए, और वह उस ज्ञान को कहाँ सत्यापित कर सकता है?

7.2 लागत अनुशासन: प्रत्येक रन को एक रोकने की शर्त दें

मैं किसी भी कार्य में एक रोकने की शर्त शामिल करूंगा जो विस्तार करता रह सकता है। समीक्षा के लिए, यह प्रासंगिक व्यवहार और अनसुलझे प्रश्नों का एक लिखित विवरण हो सकता है। कार्यान्वयन के लिए, यह सहमत बदलाव हो सकता है जो अपने नामित जाँचों को पास कर रहा हो।

यदि एजेंट को कोई बड़ा मुद्दा मिलता है, तो उसे वर्तमान बदलाव में उस काम को शामिल करने से पहले निष्कर्ष और मूल कार्य से उसके संबंध की व्याख्या करने के लिए कहें।

तय करें कि यह वर्तमान कार्य में शामिल है या नहीं।

परिणामों की तुलना करें और सीमाएँ लागू करें

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

कार्य और स्रोत सामग्री को स्थिर रखकर प्रयोग को निष्पक्ष रखें। यदि प्रत्येक परीक्षण प्रश्न, संदर्भ और स्वीकृति मानदंडों को बदलता है, तो तुलना की व्याख्या करना कठिन होगा।

और किसी भी खर्च नियंत्रण को वहाँ रखें जहाँ वे वास्तव में आपके टूल या प्रदाता द्वारा लागू किए जाते हैं। एक एजेंट को किफायती होने के लिए कहने वाला वाक्य एक प्राथमिकता है; किसी सीमा पर भरोसा करने से पहले उपलब्ध नियंत्रणों का निरीक्षण करें।

8. कस्टम बिल्ड: एक वास्तविक समस्या बिंदु के आसपास वर्कस्पेस बदलें

एक बार जब आप मूल चक्र पूरा कर लेते हैं, तो आपको इस बात का बेहतर अंदाजा होगा कि आप डेस्कटॉप से क्या चाहते हैं। हो सकता है कि कोई दोहराव वाला नेविगेशन चरण आपको परेशान करता हो, या कोई कार्य दृश्य किसी फ़ील्ड को आवश्यकता से अधिक कठिन बना देता हो।

किसी सुविधा का प्रस्ताव करने से पहले घर्षण को लिखें। उस क्रिया का वर्णन करें जिसे आप करने का प्रयास कर रहे हैं, जहाँ आप समय खोते हैं, और बेहतर व्यवहार आपको क्या करने देगा।

फिर स्रोत रिपॉजिटरी खोलें और अपने एजेंट को एक सीमित परिवर्तन अनुरोध दें। शामिल करें कि आप ऐप में परिणाम का निरीक्षण करने का इरादा रखते हैं।

बदलाव का निर्माण और निरीक्षण करें

रिपॉजिटरी इन डेवलपमेंट और पैकेजिंग कमांड का दस्तावेज़ीकरण करती है:

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

डेवलपमेंट कमांड

SwiftUI परिवर्तनों का निरीक्षण करने के लिए पुनर्निर्माण और पुनरारंभ की आवश्यकता होती है। डेस्कटॉप वर्कफ़्लो

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

उसी मानक का उपयोग करें जो आपने एक्सपोर्ट अभ्यास पर लागू किया था: एक ठोस पहले, एक सीमित बदलाव, और एक देखा गया बाद।

8.1 रिमोट विकल्प: तय करें कि काम कहाँ रहना चाहिए

स्थानीय वर्कफ़्लो के काम करने के बाद, आप एक स्थायी सर्वर पर निष्पादन चाह सकते हैं। सेल्फ-होस्टिंग पथ मूल ऐप को एक एकल-मालिक सेवा से जोड़ता है जो अपने प्रोजेक्ट, मेमोरी, टास्क हिस्ट्री और CLI साइन-इन का मालिक है; होस्ट स्विच करने से आपके Mac का डेटा या क्रेडेंशियल स्वचालित रूप से स्थानांतरित नहीं होता है। होस्टिंग गाइड

मैं यह कदम किसी ठोस कारण से उठाऊंगा, जैसे किसी प्रोजेक्ट और उसके निष्पादन वातावरण को उस मशीन पर रखना जिसे आप पहले से बनाए रखते हैं। डिप्लॉयमेंट का काम शुरू करने से पहले उस कारण को लिख लें।

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

चयनित वातावरण को सत्यापित करें

फिर वहाँ एक परिचित कार्य दोहराएं। चयनित प्रोजेक्ट की जाँच करें, पुष्टि करें कि एजेंट इच्छित स्रोत तक पहुँच सकता है, और सत्यापित करें कि परिणाम आपके द्वारा चुने गए सर्वर वातावरण का है।

किसी ज्ञात कार्य का उपयोग करने से संक्रमण का आकलन करना आसान हो जाता है। यदि आप एक साथ होस्ट, प्रोजेक्ट और वर्कफ़्लो बदलते हैं, तो यह पहचानना मुश्किल हो जाता है कि किस बदलाव ने कोई आश्चर्यजनक परिणाम दिया।

मूल पैटर्न सीखने के लिए स्थानीय वातावरण पर्याप्त है। बुनियादी ढाँचे का विस्तार तब करें जब काम आपको कोई कारण दे।

9. स्केलिंग: वहाँ कवरेज जोड़ें जहाँ पिछले चक्र ने कोई कमी दिखाई

मैं इस सेटअप का विस्तार वास्तविक कार्यों के दौरान सामने आने वाले लापता संदर्भ के अनुसार करूंगा।

• यदि किसी समीक्षा के लिए पहले की किसी आर्किटेक्चर चर्चा की आवश्यकता थी, तो उस चर्चा को आयात करें।
• यदि कार्यान्वयन के लिए बार-बार एक ही प्रक्रिया की आवश्यकता थी, तो एक कौशल विकसित और सत्यापित करें।
• यदि कोई निर्णय बार-बार खोला जा रहा है, तो उसका समर्थन करने वाले साक्ष्य के साथ एक सीमित पाठ लिखें।

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

विस्तार तब करें जब काम इसे उचित ठहराए

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

उन हिस्सों का विस्तार करें जिन्होंने अपना स्थान अर्जित किया है। बाकी को इतना सरल रखें कि जब कुछ गलत हो तो समझा जा सके।

9.1 रखरखाव की आदत: जब सिस्टम बदलता है तब ज्ञान की पुनरावृत्ति करें

मैं प्रासंगिक पाठों की समीक्षा तब करूंगा जब कोई उप-प्रणाली उनकी मान्यताओं को बदलने के लिए पर्याप्त रूप से बदल जाए। परिवर्तन को ही ट्रिगर के रूप में उपयोग करें: एक नई निर्भरता, एक बदली हुई स्टोरेज लेयर, एक अलग डिप्लॉयमेंट वातावरण, या एक संशोधित उत्पाद आवश्यकता।

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

महत्वपूर्ण भाग स्पष्टीकरण को संरक्षित करना है। भविष्य के निर्माता को यह समझने में सक्षम होना चाहिए कि पहले का नियम क्यों मौजूद था और इसे बदलने के लिए क्या पर्याप्त बदल गया।

प्रक्रियाओं को ताज़ा करें और विरोधों को हल करें

कौशल के लिए, इसके इनपुट या कमांड को प्रभावित करने वाले परिवर्तन के बाद प्रक्रिया को फिर से चलाएं। यदि कोई चरण अब काम नहीं करता है, तो देखी गई विफलता के आधार पर प्रक्रिया को अपडेट करें और प्रासंगिक जाँच दोहराएं।

यह रखरखाव को प्रोजेक्ट की वास्तविक घटनाओं से जोड़े रखता है। आप उस ज्ञान की समीक्षा कर रहे हैं जिसके पुराना होने की सबसे अधिक संभावना है, जिसमें वर्तमान साक्ष्य पहले से ही आपके सामने हैं।

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

एक उपयोगी हैंडओवर छोड़ें

अगले सत्र से पहले, एक छोटा हैंडओवर छोड़ें जिसमें सत्यापित परिणाम, खुला प्रश्न और वह स्रोत शामिल हो जिसे किसी अन्य एजेंट को पहले पढ़ना चाहिए। इसे उस प्रोजेक्ट स्थिति के लिए विशिष्ट रखें जिसकी आपने वास्तव में जाँच की थी।

यह कल के काम को एक प्रारंभिक बिंदु देता है जिसे आप ट्रेस कर सकते हैं, खासकर जब आप किसी भिन्न टूल के माध्यम से या समय बीतने के बाद लौटते हैं, जिसमें मूल तर्क अभी भी उपलब्ध हो।

10. बिल्ड शीट

1. एक परिचित रिपॉजिटरी और एक ऐसा निर्णय चुनें जिसे आप पहचान सकें।
2. डेस्कटॉप बनाएं, सेटअप पूरा करें, और उस निर्णय वाली एक पूर्ण वार्तालाप आयात करें।
3. उसे खोजें, स्रोत का निरीक्षण करें, और वर्तमान कोड की केवल-पढ़ने योग्य समीक्षा से संलग्न करें।
4. स्वयं निष्कर्षों की जाँच करें, फिर एक दृश्य स्वीकृति शर्त के साथ एक सीमित कार्यान्वयन का ब्रीफ करें।
5. डिफ़ का निरीक्षण करें और प्रासंगिक सत्यापन चलाएं, जिसमें वह विफलता मामला भी शामिल है जिसने काम को प्रेरित किया।
6. केवल तभी पाठ तैयार करें जब परिणाम इसका समर्थन करता हो, जिसमें दायरा और कारण दर्ज हो।
7. किसी प्रक्रिया को कौशल में तभी बदलें जब आपने सत्यापित कर लिया हो कि इसे दोहराना उचित है।
8. किसी अन्य टूल से समान पुनर्प्राप्ति का प्रयास करें, फिर अपने संदर्भ या बुनियादी ढाँचे का विस्तार करें जब कोई वास्तविक कार्य इसकी आवश्यकता हो।

इस सप्ताह एक निर्णय से शुरुआत करें, और अपना पूरा इतिहास आयात करने से पहले इसे पूरे चक्र में ले जाएं।

अगले एजेंट को आपका निर्णय विरासत में मिलना चाहिए।