AI चैट में लिए गए फ़ैसले क्यों खो जाते हैं, और उन्हें कहाँ रखें

ChatGPT या Claude की बातचीत में लिए गए फ़ैसले इसलिए खो जाते हैं क्योंकि चैट की कोई स्थिति (state) नहीं होती। उसमें कुछ भी किसी लाइन को "यह हमने तय किया" के रूप में चिह्नित नहीं करता, कुछ भी उस लाइन को उस काम से नहीं जोड़ता जिस पर उसका असर है, और नई चैट ख़ाली शुरू होती है। इलाज यह है कि AI फ़ैसले को वहीं लिखे जहाँ काम रहता है, कारणों के साथ एक छोटे रिकॉर्ड के रूप में, और अगला सेशन कुछ करने से पहले वे रिकॉर्ड पढ़े।

Weft हम बनाते हैं। दूसरे प्रोडक्टों के बारे में तथ्य उनके आधिकारिक पेजों से हैं, जिन्हें 27 अक्टूबर 2026 को जाँचा गया। यह विचार कि थ्रेड की "कोई स्थिति नहीं होती", Slack थ्रेड पर Hypertask के लेख से आया है। यह गाइड इसे AI चैट पर लागू करती है।

ChatGPT या Claude के साथ लिए गए फ़ैसले ग़ायब क्यों हो जाते हैं?

आप चालीस मिनट एक असिस्टेंट के साथ दो डेटाबेस प्रोवाइडर, दो प्राइसिंग मॉडल या API के ढाँचे के दो तरीकों को तौलते हैं। आप एक पर तय करते हैं। तर्क अच्छा है, असिस्टेंट सहमत है, और आप अगली चीज़ पर बढ़ जाते हैं।

एक हफ़्ते बाद नतीजा अब भी उसी चैट में है, कहीं दो सौ दूसरे संदेशों के ऊपर। नई चैट को इसके बारे में कुछ नहीं पता। टीम के किसी साथी ने इसे कभी देखा नहीं। और अगर अगले दिन आप कोई दूसरा AI क्लाइंट खोलते हैं, जैसे टर्मिनल में कोडिंग एजेंट, तो वह शून्य से शुरू करता है और ख़ुशी-ख़ुशी वही विकल्प सुझा सकता है जिसे आपने ठुकरा दिया था।

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

क्या चैट की memory यह पहले से हल नहीं करती?

इस काम के लिए नहीं। कई असिस्टेंट अब चैटों के बीच आपके बारे में बातें याद रख सकते हैं, और यह पसंद-नापसंद और पृष्ठभूमि के लिए काम का है। पर वह memory एक प्रोडक्ट और एक अकाउंट की है। वह उसी असिस्टेंट के इस्तेमाल के लिए लिखी जाती है, ऐसे रिकॉर्ड के रूप में नहीं जिसे कोई व्यक्ति लाइन-दर-लाइन रिव्यू कर सके, और दूसरा AI क्लाइंट उसे पढ़ नहीं सकता। वह यह भी नहीं बताती कि कोई चुनाव किस टास्क के बारे में था या उसने किस पुराने चुनाव की जगह ली।

Decision log की ज़रूरतें अलग हैं। उसे प्रोजेक्ट पर काम करने वाले लोग और एजेंट ढूँढ़ सकें, अगला काम उठाने वाला कोई भी AI क्लाइंट उसे पढ़ सके, वह उस काम से जुड़ा हो, और इतिहास के बारे में ईमानदार हो: जब कोई फ़ैसला बदले, तो पुराना उस कारण के साथ दिखता रहे जिससे उसकी जगह ली गई।

कौन-सा फ़ैसला दर्ज करने लायक है?

कोई चुनाव तब दर्ज करें जब कोई समझदारी से अलग चुन सकता था और यह चुनाव आगे के काम को आकार देगा। अच्छे उदाहरण:

• एक टूल, वेंडर या लाइब्रेरी को दूसरे पर चुनना।
• किसी चीज़ को जानबूझकर छोड़ना ("इस तिमाही कोई referral प्रोग्राम नहीं")।
• ऐसा नियम तय करना जिसका काम को पालन करना है ("EU में सारी कीमतें VAT सहित दिखें")।
• किसी पुराने चुनाव को बदलना, कारण के साथ।
• ठोकर खाकर सीखा गया सबक़ ("कामकाजी घंटों में migration मत चलाओ")।

इन्हें दर्ज न करें:

• विचार जो आपने रखे पर अपनाए नहीं।
• ख़ुद काम के कदम (वे टास्क और उसके नतीजे में आते हैं)।
• कुछ भी जिस पर व्यक्ति अभी सहमत नहीं हुआ, जब तक उसे साफ़ तौर पर प्रस्तावित न चिह्नित किया जाए।
• ऐसे तथ्य जिन्हें कोई भी एक मिनट में फिर से देख सकता है।

एक काम की कसौटी: अगर कोई नया AI सेशन इस चुनाव को पलटने वाला हो, तो क्या आप चाहेंगे कि वह रुककर पढ़े कि क्यों? अगर हाँ, तो इसे दर्ज करें।

अच्छा decision record कैसा दिखता है?

इसे छोटा रखें और कारण बनाए रखें। नीचे का फ़ॉर्मेट MADR (Markdown Architectural Decision Records) का हल्का रूप है, और Weft का record_decision टूल यही इस्तेमाल करता है:

Title:        फ़ाइल अपलोड: डेटाबेस नहीं, object storage
Outcome:      अपलोड की गई फ़ाइलें object storage में जाती हैं; डेटाबेस सिर्फ़
              फ़ाइल की key और मेटाडेटा रखता है।
Status:       accepted
Context:      उपयोगकर्ता 50 MB तक की फ़ाइलें जोड़ते हैं। उन्हें डेटाबेस में
              रखने से बैकअप धीमे और बड़े हो जाते।
Options:      1. Object storage  + सस्ता, बैकअप छोटे रहते हैं
                                 - सेट करने को एक और सर्विस
              2. डेटाबेस कॉलम    + सब कुछ एक जगह
                                 - हर अपलोड के साथ बैकअप बढ़ते हैं
Consequences: डाउनलोड के लिए signed URLs चाहिए।
              टास्क डिलीट करने पर उसकी फ़ाइलें भी डिलीट होनी चाहिए।
Revisit when: जब फ़ाइलों के अंदर सर्च करने की ज़रूरत पड़े।
Task:         फ़ाइल अपलोड

• Title फ़ैसले को नाम देता है ताकि सरसरी नज़र में मिल जाए।
• Outcome एक वाक्य है जिस पर कोई नया व्यक्ति अमल कर सके।
• Context वह है जो उस समय सच था। यही हिस्सा याददाश्त से सबसे पहले मिटता है।
• Options में सिर्फ़ वे हैं जो असल में तौले गए, बाद में गढ़े गए विकल्प नहीं।
• Consequences में वे कमियाँ भी हैं जिन्हें आपने स्वीकार किया, ताकि बाद में कोई उन्हें बग के रूप में "खोज" न ले।
• Revisit when बताता है कि किस बात से यह चुनाव ग़लत हो जाएगा।

Weft decision record कैसे रखता है?

Weft एक टास्क बोर्ड है जिस तक आपके AI क्लाइंट MCP पर https://letsweft.com/api/mcp से पहुँचते हैं। उसके 32 टूल में से तीन फ़ैसले संभालते हैं:

• record_decision एक टाइटल और नतीजा लेता है, साथ में संदर्भ, फ़ायदे-नुक़सान वाले पाँच तक विकल्प, परिणाम और दोबारा देखने की शर्त। इसे किसी टास्क (taskId) या प्रोजेक्ट से जोड़ा जा सकता है। रिकॉर्ड बदले नहीं जा सकते: बदलने के लिए AI पुराने की ओर इशारा करते supersedesId के साथ नया फ़ैसला दर्ज करता है, और पुराना रिकॉर्ड superseded चिह्न के साथ बना रहता है।
• get_context वर्कस्पेस के चालू फ़ैसले और सबक़ लौटाता है, सबसे नए पहले, एक टोकन बजट में समेटकर (डिफ़ॉल्ट 800 टोकन)। इसे किसी प्रोजेक्ट या टास्क तक सीमित किया जा सकता है। हर लाइन में उसकी तारीख़ होती है, superseded फ़ैसला कभी नहीं दिखता, और जो लाइनें नहीं समाईं उन्हें छिपाया नहीं, गिना जाता है।
• get_task_history decisions मोड में एक टास्क के बारे में दर्ज हर फ़ैसला दिखाता है, रिव्यू के फ़ैसलों और उनके कारणों समेत।

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

क्योंकि रिकॉर्ड कभी अपनी जगह पर बदले नहीं जाते, इतिहास ईमानदार रहता है। अगर आप मार्च में प्रोवाइडर बदलते हैं, तो जनवरी का फ़ैसला superseded चिह्न के साथ अब भी वहाँ है, और मार्च का रिकॉर्ड बताता है कि क्यों।

अपने AI से फ़ैसले दर्ज करने को कैसे कहूँ?

Weft को अपने AI क्लाइंट से जोड़ें, फिर चैट की शुरुआत में, या अगर क्लाइंट में custom instructions या प्रोजेक्ट फ़ाइल है तो उसमें, ऐसा निर्देश पेस्ट करें:

जब हम इस चैट में कोई असली चुनाव करें (एक विकल्प को दूसरे पर चुनें,
कुछ छोड़ दें, या कोई पुराना चुनाव बदलें), तो आगे बढ़ने से पहले उसे
record_decision से Weft में दर्ज करो:
- title: फ़ैसला, कुछ शब्दों में
- outcome: चुनाव, एक वाक्य में
- context: क्या सच था जिसने यह चुनाव करवाया
- options: सिर्फ़ वे विकल्प जो हमने असल में तौले, फ़ायदे-नुक़सान के साथ
- consequences: आगे क्या होगा, अच्छा और बुरा
- confirmation: हमें इसे कब दोबारा देखना चाहिए
- taskId या project: यह किस टास्क या प्रोजेक्ट के बारे में है
अगर यह किसी पुराने फ़ैसले को बदलता है, तो बदलने के बजाय supersedesId दो।
इधर-उधर की बातें, अंदाज़े, या जिन पर मैं सहमत नहीं हुआ, दर्ज मत करो।
अगर मैंने अभी पक्का नहीं किया है, तो status "proposed" रखो।
किसी भी गंभीर काम की शुरुआत में पहले get_context कॉल करो और मुझे बताओ
कि कौन-से पुराने फ़ैसले लागू होते हैं।

जोड़ने में एक मिनट लगता है। ChatGPT में Weft प्लगइन डायरेक्टरी में प्रकाशित ऐप है, Free समेत हर प्लान पर उपलब्ध (सेटअप)। Claude Code में यह एक कमांड है (सेटअप)। Claude.ai और Claude Desktop इसे custom connector के रूप में जोड़ते हैं। साइन-इन ब्राउज़र में OAuth से होता है, इसलिए कॉपी करने को कोई key नहीं, और Weft refresh token देता है, इसलिए क्लाइंट साइन-इन ख़ुद रिन्यू करता है। Cursor और Codex समेत दूसरे क्लाइंट के सेटअप पेज डॉक्स में हैं।

अगले दिन ChatGPT से Claude Code पर जाऊँ तो क्या होता है?

यह वही मामला है जिसके लिए यह निर्देश बना है।

1. सोमवार को आप ChatGPT में एक फ़ीचर की योजना बनाते हैं। आप तय करते हैं कि अपलोड डेटाबेस के बजाय object storage में रखे जाएँ, और ChatGPT संदर्भ, दोनों विकल्पों और परिणामों के साथ record_decision कॉल करता है, "फ़ाइल अपलोड" टास्क से जोड़कर।
2. मंगलवार को आप रिपॉज़िटरी में Claude Code खोलते हैं। अगर आपने अभी तक इसे नहीं जोड़ा: claude mcp add --transport http weft https://letsweft.com/api/mcp।
3. आप उससे अपलोड वाला टास्क उठाने को कहते हैं। कोड लिखने से पहले वह उस टास्क के लिए get_context, या decisions मोड में get_task_history, कॉल करता है और सोमवार का रिकॉर्ड वापस पाता है।
4. वह सवाल को फिर से खोलने के बजाय object storage पर काम करता है। अगर उसे कोई असली कारण मिले कि चुनाव ग़लत है, तो वह सोमवार वाले की जगह लेने वाला नया फ़ैसला प्रस्तावित कर सकता है, और फ़ैसला आप करते हैं।

दोनों क्लाइंट एक ही बोर्ड और एक ही फ़ैसले पढ़ते हैं, क्योंकि रिकॉर्ड Weft में रहता है, किसी भी चैट में नहीं। हर OAuth कनेक्शन अपना अलग actor है, और बोर्ड हर क्लाइंट का वही नाम दिखाता है जिससे उसने रजिस्टर किया, इसलिए आप देख सकते हैं कि किस कनेक्शन ने कौन-सा टास्क बनाया। बिना टकराव के एक बोर्ड पर कई एजेंट चलाने के लिए देखें एक बोर्ड पर कई AI एजेंट।

ChatGPT के फ़ैसले आख़िर कहाँ रखे जाएँ?

चार आम जगहें, decision log की ज़रूरतों के आधार पर तुलना:

बात यह नहीं कि चैट या डॉक बुरे हैं। चैट वह जगह है जहाँ आप सोचते हैं। फ़ैसले को, लिए जाते ही, चैट से निकालकर किसी स्थिति वाली चीज़ में डालना होता है, और यह वही करे जो पहले से बातचीत में मौजूद है: AI।

क्या यह हमारे डॉक्स या wiki की जगह लेता है?

नहीं। Weft में डॉक्स या wiki नहीं है, और वह ऐसा बनने की कोशिश भी नहीं करता। लंबी व्याख्याएँ, onboarding गाइड और डिज़ाइन के लेख आपके डॉक्स टूल में रहते हैं। Decision record जानबूझकर छोटा है: एक चुनाव, उसके कारण, और किसने उसकी जगह ली। अगर आपकी टीम पहले से wiki में decision records रखती है और आपका हर AI क्लाइंट उसे पढ़ सकता है, तो शायद वह काफ़ी है। Weft तब काम का है जब फ़ैसले AI चैट में लिए जाते हैं और अगला पढ़ने वाला अक्सर कोई दूसरा AI होता है। अगर आप इसके लिए Notion पर विचार कर रहे हैं, तो देखें AI टास्क के लिए Notion के विकल्प।

दो और ईमानदार सीमाएँ। Weft आपकी चैट नहीं पढ़ता: फ़ैसला तभी दर्ज होता है जब AI record_decision कॉल करे, इसीलिए ऊपर वाला निर्देश मायने रखता है। और AI यह ग़लत आँक सकता है कि क्या फ़ैसला है, इसलिए कभी-कभी get_context पढ़ें और जो ग़लत हुआ उसकी जगह नया दर्ज करें।

इसकी कीमत क्या है?

फ़ैसले दर्ज करना और पढ़ना Free प्लान पर चलता है, जिसमें 50 सक्रिय टास्क और महीने में 200 AI टूल कॉल शामिल हैं। हर record_decision या get_context कॉल एक कॉल गिना जाता है। Pro प्रति सीट $7 महीना या प्रति सीट $60 साल है, असीमित टास्क और कॉल के साथ (कीमतें)। Weft में कोई AI क्रेडिट नहीं: सोचने का काम आपके अपने AI क्लाइंट में होता है, और Weft सिर्फ़ बोर्ड और उसके रिकॉर्ड रखता है।

क्या मैं बस ChatGPT से चैट के अंत में फ़ैसलों का सारांश नहीं माँग सकता?

माँग सकते हैं, और इससे मदद मिलती है। पर सारांश फिर भी उसी चैट में या जहाँ आप उसे पेस्ट करें वहीं रहता है। वह टास्क से जुड़ा नहीं, दूसरा AI क्लाइंट उसे पढ़ नहीं सकता, और जब फ़ैसला बदलता है तो इसका कोई रिकॉर्ड नहीं कि उसने किसकी जगह ली। हर फ़ैसले को लिए जाते ही दर्ज करना इन तीनों से बचाता है।

क्या AI बिना कहे फ़ैसले दर्ज करेगा?

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

अगर फ़ैसला ग़लत दर्ज हुआ हो तो क्या उसे बदला जा सकता है?

अपनी जगह पर नहीं। रिकॉर्ड बदले नहीं जा सकते। ग़लत वाले की ओर इशारा करते supersedesId के साथ सुधारा हुआ फ़ैसला दर्ज करें। पुराना रिकॉर्ड superseded चिह्न के साथ बना रहता है, और get_context उसे दिखाना बंद कर देता है।

क्या फ़ैसलों के लिए टास्क ज़रूरी है?

नहीं। फ़ैसला किसी टास्क से, किसी प्रोजेक्ट से, या किसी से नहीं जुड़ा हो सकता है। टास्क से जोड़ने का मतलब है कि get_task_history उसे उस काम के पास दिखाता है, और get_context को उस तक सीमित किया जा सकता है।

क्या यह Weft की work memory जैसा ही है?

नहीं। Work memory (छोटे सीखे हुए नोट्स) एक अलग Pro फ़ीचर है। Decision records, record_decision से आते हैं, और कोड उन्हें Pro तक सीमित नहीं करता।

अगर मैं एक से ज़्यादा AI क्लाइंट इस्तेमाल करूँ तो?

यही ऐसा करने की मुख्य वजह है। एक ही Weft वर्कस्पेस से जुड़े ChatGPT, Claude Code, Cursor या Codex सब get_context से वही फ़ैसले पढ़ते हैं, इसलिए दूसरा क्लाइंट उन सवालों को फिर से नहीं खोलता जिन्हें पहले ने सुलझा दिया।