Trae डिबगिंग टूल का लूप कहाँ ठहर जाता है
सोर्स से डिबग करने वाला एजेंट पढ़ सकता है, तर्क कर सकता है और एडिट कर सकता है। वह देख नहीं सकता। ऑब्ज़र्वेशन आप दे रहे हैं — शब्दों में, याददाश्त के भरोसे — और यह रास्ता बहुत सँकरा है। इससे वही पहुँचता है जो आपने गौर किया, और वह छूट जाता है जिसे आपने ज़रूरी नहीं समझा, जबकि अक्सर असली बात वही होती है।
ठहराव तब आता है जब आपके विवरण से बन सकने वाली सारी परिकल्पनाएँ एजेंट आज़मा चुका होता है। और राउंड चलाने से कुछ नहीं मिलता, क्योंकि इनपुट में कोई सुधार हुआ ही नहीं।
तीन तरह के बग जिन पर इसकी मार सबसे ज़्यादा पड़ती है
टाइमिंग
डेटा आने से पहले ही कुछ रेंडर हो जाता है, या कंपोनेंट हट जाने के बाद कोई रिक्वेस्ट पूरी होती है।
diff में देख पाना नामुमकिन, पर होते हुए देखिए तो बिलकुल साफ़।
बचा हुआ स्टेट
पहला एक्शन काम करता है और दूसरा नहीं, क्योंकि कुछ रीसेट नहीं हुआ था।
बिलकुल नए सिरे से शुरू होने वाला रिप्रोडक्शन इसे कभी नहीं दिखाएगा।
एनवायरनमेंट का बेमेल
कोड सही है और एनवायरनमेंट सहमत नहीं: कोई वेरिएबल गायब, पुराना कैश, अलग डेटा।
एजेंट उस कोड को ठीक करता रहता है जो कभी टूटा ही नहीं था।
ऑब्ज़र्वेशन वाला कदम जोड़िए
आपने जो देखा उसका ब्यौरा देने के बजाय, किसी चीज़ से डिप्लॉय किए गए एप्लिकेशन को चलवाइए और जो हुआ उसकी रिपोर्ट लीजिए। तब एजेंट को जो नतीजा मिलता है वह याददाश्त नहीं, एक रिकॉर्ड होता है: क्या आज़माया गया, ऐप ने क्या किया, और दोनों कहाँ अलग हुए।
सेटअप यह क्षमता एजेंट के भीतर इंस्टॉल कर देता है, ताकि वह आपके बताने का इंतज़ार करने के बजाय अपने सबूत खुद तैयार करे और खुद पढ़े।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप स्थानीय तौर पर कुछ भी इंस्टॉल नहीं करना चाहते, तो यही सेटअप TestSprite डैशबोर्ड में भी उपलब्ध है। CLI का बाकी हिस्सा आपको यहाँ मिलेगा — CLI रिपॉज़िटरी.
दो सवाल जो ठहराव तोड़ देते हैं
क्या यह बिलकुल साफ़ शुरुआत से भी फेल होता है? अगर हाँ, तो यह लॉजिक की समस्या है। अगर सिर्फ़ दूसरी कोशिश में, तो यह बचा हुआ स्टेट है, और अब तक की हर कोड-स्तरीय परिकल्पना गलत चीज़ पर निशाना लगा रही थी।
क्या यह किसी दूसरे एनवायरनमेंट में फेल होता है? अगर एक ही बिल्ड दो जगह अलग-अलग बर्ताव करता है, तो कोड एडिट करना बंद कीजिए। दोनों एनवायरनमेंट के बीच का फ़र्क़ ही बग है।
दोनों का जवाब निकालना सस्ता है, और जवाब चौंकाने वाला निकले तो दोनों पूरे सेशन की दिशा बदल देते हैं।
फ़िक्स के बाद भी रिप्रोडक्शन संभालकर रखिए
बग को देखने के लिए आपने जो केस बनाया था, वही वह जाँच है जो उसे लौटने से रोकती है। उसे बातचीत के साथ मिटा देने के बजाय हर बदलाव पर चलाइए।
मैकेनिज़्म से ज़्यादा मायने ट्रिगर रखता है। इसे अपने डिप्लॉयमेंट इवेंट से जोड़ देने का मतलब है कि हर बदलाव की जाँच बिना किसी के तय किए हो जाती है; GitHub App यह काम डैशबोर्ड से करता है, और GitHub Actions स्टेप इसे आपके वर्कफ़्लो के भीतर से करता है।
एजेंट बार-बार मिलते-जुलते फ़िक्स क्यों सुझाता रहता है?
क्योंकि इनपुट बदला ही नहीं है। नए ऑब्ज़र्वेशन के बिना वह उसी परिकल्पना-क्षेत्र को दोबारा टटोल सकता है, बस शब्द बदले हुए होते हैं।
क्या मुझे और लॉग पेस्ट करने चाहिए?
ज़्यादा सिग्नल से मदद मिलती है, पर लॉग यह बताते हैं कि कोड ने क्या तय किया, न कि यूज़र को क्या अनुभव हुआ। असली एप्लिकेशन पर चलाया गया रन उस खाली जगह को भर देता है जो लॉग छोड़ जाते हैं।
क्या यह सिर्फ़ Trae की बात है?
नहीं। सोर्स से डिबग करने वाले हर एजेंट में यही अंधा कोना होता है। वर्कफ़्लो अलग होता है, छूटा हुआ कदम वही रहता है।
अगर मैं इसे भरोसे के साथ दोबारा न दिखा पाऊँ तो?
तब रुक-रुक कर होना ही निष्कर्ष है। एक ही केस को कई बार चलाइए और तुलना कीजिए। चार में से एक बार फेल होने वाला फ़्लो टाइमिंग या स्टेट की समस्या है, और इससे खोज का दायरा काफ़ी सिमट जाता है।
क्या फ़िक्स की पुष्टि अलग से करनी ज़रूरी है?
हाँ। जिस तर्क ने फ़िक्स सुझाया और उसी ने उसकी पुष्टि भी कर दी, उसमें कोई स्वतंत्र सबूत नहीं होता। ठीक हुए व्यवहार को किसी न किसी को देखना ही होगा।
लूप को एक और राउंड नहीं, एक ऑब्ज़र्वेशन चाहिए।
Trae डिबगिंग टूल सेशन तब ठहर जाता है जब आपके विवरण से बन सकने वाली परिकल्पनाएँ एजेंट के पास खत्म हो जाती हैं। उसे चलते हुए ऐप के असली ऑब्ज़र्वेशन दीजिए, पूछिए कि साफ़ शुरुआत और अलग एनवायरनमेंट में भी वह फेल होता है या नहीं, और रिप्रोडक्शन को स्थायी जाँच के तौर पर बनाए रखिए।