वॉल्ट संरचना और डीबगिंग
एक मार्कडाउन वॉल्ट को खोज योग्य दूसरी मेमोरी के रूप में व्यवस्थित करें। जब Claude कुछ अप्रत्याशित करता है तो चार विफलता मोड का निवारण करें।
STATE.md और MEMORY.md में वह सब कुछ होता है जिसकी हर सत्र को आवश्यकता होती है। एक मार्कडाउन वॉल्ट (ऑब्सीडियन या कोई भी फ़ोल्डर) बाकी सब कुछ रखता है: रणनीति नोट्स, मीटिंग ट्रांसक्रिप्ट, प्रोजेक्ट जर्नल, शोध, प्रतिस्पर्धी विश्लेषण।
वॉल्ट संस्थागत मेमोरी में विकसित होता है: छह महीने पहले आपने जो निर्णय लिए थे और क्यों, संदर्भ सामग्री जो वर्तमान कार्य को सूचित करती है, पैटर्न जो परियोजनाओं में फैले हुए हैं। इसे एक ऑब्सीडियन या फ़ाइलसिस्टम MCP के माध्यम से कनेक्ट करें और Claude मांग पर पूरी चीज़ खोज सकता है। वॉल्ट के बिना, यह ज्ञान केवल आपके सिर में या पुराने दस्तावेज़ों में दफन रहता है।
मार्कडाउन डेटाबेस से बेहतर क्यों है: सादी फ़ाइलें ग्रेपेबल होती हैं, गिट के साथ संस्करण होती हैं, किसी भी संपादक में खुलती हैं, और हर टूल परिवर्तन से बची रहती हैं। एक कार्यशील संरचना:
~/notes/
├── STATE.md # हमेशा लोड किया गया
├── MEMORY.md # इंडेक्स, हमेशा लोड किया गया
├── STRATEGY-DIGEST.md # रणनीति दस्तावेज़ों का सारांश
├── strategy/ # पूर्ण दस्तावेज़, मांग पर पढ़ें
├── projects/ # दिनांकित प्रोजेक्ट नोट्स
├── resources/
└── reference/स्केलिंग कुंजी डाइजेस्ट पैटर्न है: जब आप 1,000-शब्दों का रणनीति दस्तावेज़ लिखते हैं, तो उसके साथ एक 3-वाक्य का डाइजेस्ट लिखें और डाइजेस्ट को MEMORY.md में इंडेक्स करें। Claude सत्र की शुरुआत में पूर्ण दस्तावेज़ के लगभग 1,500 के बजाय लगभग 50 टोकन पढ़ता है। 25 रणनीति दस्तावेज़ों पर, यह 37,500 के मुकाबले 1,250 टोकन है, और सत्र तेज़ रहते हैं।
जब Claude कुछ अप्रत्याशित करता है, तो चार विफलता मोड को क्रम से जाँचें, सबसे आम से कम आम तक:
पुरानी मेमोरी: STATE.md एक बात कहता है, वास्तविकता दूसरी बात कहती है। Claude ने आपके निर्देशों का पूरी तरह से पालन किया; निर्देश गलत थे। हर बार पहले "मुझे अपना STATE.md दिखाओ" पूछें।
गायब संदर्भ: प्रासंगिक फ़ाइल कभी लोड नहीं हुई, इसलिए Claude ने एक उचित अनुमान लगाया। फ़ाइल को स्पष्ट रूप से लोड करें और फिर से पूछें।
उपकरण अनुपलब्ध: एक MCP डाउन है या एक हुक ने एक कमांड को ब्लॉक कर दिया है, और Claude ने इसके चारों ओर बुरी तरह से काम किया। तर्क को दोष देने से पहले उपकरण की उपलब्धता की जाँच करें।
भ्रम: सबसे दुर्लभ कारण। पहले सत्यापित करें: फ़ंक्शन के लिए grep करें, जाँच करें कि एंडपॉइंट मौजूद है। अधिकांश "भ्रम" पहले तीन में से एक निकलते हैं।
प्रत्येक विफलता मोड के लिए एक नैदानिक प्रश्न:
पुरानी मेमोरी: "आपके STATE.md में [विषय] के बारे में क्या लिखा है?" तीन सत्र पहले की सामग्री का मतलब पुरानी स्थिति है।
गायब संदर्भ: "आपके पास [विषय] के बारे में कौन सी फ़ाइलें लोड हैं?" कोई प्रासंगिक फ़ाइलें नहीं होने का मतलब है सही फ़ाइल लोड करें।
उपकरण अनुपलब्ध: "आपके पास अभी कौन से उपकरण उपलब्ध हैं?"
भ्रम: "[फ़ंक्शन/एंडपॉइंट] के लिए grep करें और मुझे दिखाएं कि आपको क्या मिलता है।"
यह अनुक्रम दो मिनट लेता है और लगभग हर बार कारण का पता लगाता है। सीधे "Claude भ्रमित हो गया" पर कूदना आमतौर पर उस कोड को फिर से लिखकर वास्तविक समाधान में देरी करता है जिसे फिर से लिखने की आवश्यकता नहीं थी।
रोकथाम डीबगिंग से बेहतर है। आदतें:
सत्र के अंत में STATE.md अपडेट। 80% पुरानी मेमोरी समस्याओं को समाप्त करता है।
शिप किए गए प्रोजेक्ट को दिनांकित project_* फ़ाइलों में संग्रहीत करें।
मासिक MEMORY.md ऑडिट: पुष्टि करें कि हर पॉइंटर अभी भी एक मौजूदा फ़ाइल की ओर इशारा करता है।
500 शब्दों से अधिक के हर दस्तावेज़ का डाइजेस्ट करें।
निर्णय के क्षण में निर्णय लिखें, न कि सप्ताह के अंत में। पूर्वव्यापी कैप्चर तर्क खो देता है।
प्रोजेक्ट नोट्स को संग्रहीत करने से पहले, स्थायी पाठों को feedback_* प्रविष्टियों में निकालें। प्रोजेक्ट इतिहास बन जाता है; पाठ सक्रिय रहते हैं।
10 अच्छी तरह से बनाए गए दस्तावेज़ों वाला एक वॉल्ट 200 पुराने दस्तावेज़ों वाले वॉल्ट से बेहतर है। गुणवत्ता और मुद्रा मात्रा से बेहतर है।
एक ऑब्सीडियन या फ़ाइलसिस्टम MCP के साथ, वॉल्ट एक लाइव ज्ञान आधार बन जाता है:
निर्णय पुरातत्व: "वॉल्ट में खोजें कि हमने MySQL के बजाय Postgres क्यों चुना।" 10 मिनट की मैन्युअल खोज 15 सेकंड बन जाती है।
पैटर्न का पता लगाना: "परियोजनाओं में दर सीमित करने की समस्याओं या 429 त्रुटियों के सभी उल्लेख खोजें।" Claude पांच प्रोजेक्ट फ़ाइलों में फैले एक सामान्य मूल कारण को सतह पर लाता है।
संदर्भ लुकअप: "विक्रेता नोट्स में संपर्क जानकारी खोजें।" अनुक्रमित फ़ाइलों से तत्काल पुनर्प्राप्ति।
खोज गुणवत्ता नामकरण संगति पर निर्भर करती है: project_[name]_[date].md और feedback_[rule].md उस समय जो स्वाभाविक लगा उससे बेहतर हैं। नामकरण परंपराएं वह इंडेक्स हैं जिसे आप इसकी आवश्यकता से पहले बनाते हैं।
सभी चार मोड साफ-सुथरे निकलते हैं और आउटपुट अभी भी गलत है? दो कारण भ्रम जैसे दिखते हैं लेकिन नहीं हैं।
संदर्भ क्रम: जब लोड की गई फ़ाइलें टकराती हैं, तो बाद में लोड की गई सामग्री जीतने की प्रवृत्ति रखती है। यदि पुराने प्रोजेक्ट नोट्स STATE.md का खंडन करते हैं, तो स्पष्ट रूप से अधिकार असाइन करें: "STATE.md वर्तमान जमीनी सच्चाई है। यह प्रोजेक्ट नोट्स में किसी भी चीज़ को अधिलेखित करता है।"
बाधा टकराव: CLAUDE.md कहता है "सभी SQL को पैरामीटर करें," इसलिए Claude SQL को फिर से लिखता है जिसे आप केवल शैली-केवल रीफैक्टर के रूप में मानते थे। यह कोई बग नहीं है; इसे स्पष्ट रूप से स्कोप करें: "केवल शैली, SQL पैटर्न न बदलें।"
दोनों के लिए निदान: "आप किन निर्देशों का पालन कर रहे हैं जो [इस निर्णय] को नियंत्रित करते हैं? नियमों को प्राथमिकता क्रम में सूचीबद्ध करें।" आपको एक पुराना स्रोत, एक विरोधाभासी नियम, या एक CLAUDE.md अंतर मिलेगा। सभी ठीक करने योग्य हैं।
डाइजेस्ट फ़ाइलों वाला एक मार्कडाउन वॉल्ट आपकी दूसरी मेमोरी को बढ़ाता है; डाइजेस्ट सत्रों को तेज़ रखते हैं, पूर्ण दस्तावेज़ मांग पर लोड होते हैं। जब Claude गलत व्यवहार करता है, तो क्रम में जांच करें: पुरानी मेमोरी, गुम संदर्भ, उपकरण अनुपलब्ध, मतिभ्रम, और हमेशा "मुझे अपना STATE.md दिखाओ" से शुरू करें। निर्णय के क्षण में वॉल्ट को फ़ीड करें और यह हर हफ्ते मूल्य में वृद्धि करता है।