Cursor डिबगिंग टूल: फिक्स लूप क्यों अटक जाता है

Cursor डिबगिंग टूल का सेशन क्यों अटक जाता है

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

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

वे तीन विवरण जो एजेंट को भटका देते हैं

लूप को बंद क्या करता है

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

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

सेटअप Cursor के भीतर ही एक वेरिफिकेशन स्किल इंस्टॉल कर देता है, ताकि उसे पता हो कि केस कैसे बनाना है, उसे चलाना कैसे है और नतीजा कैसे पढ़ना है — बिना आपके हर बार वर्कफ़्लो समझाए।

यही सब आप TestSprite डैशबोर्ड से भी कर सकते हैं। CLI और जो कुछ करता है, वह सब यहाँ मिलेगा — CLI रिपॉज़िटरी।

बयान से बेहतर है एक ऐसा रीप्रो जो आप सौंप सकें

सबसे ज़्यादा फ़ायदा देने वाली आदत यही है कि बग का वर्णन करना छोड़िए और उसे दोहराना शुरू कीजिए। लिखा हुआ केस बताता है कि कौन-सा पेज खोलना है, क्या करना है, और उसके बाद क्या सही होना चाहिए। ऐसी तीन पंक्तियाँ तीन पैराग्राफ़ की सफ़ाई से बेहतर काम करती हैं, क्योंकि उनमें कोई दुविधा नहीं होती और उन्हें दोबारा चलाया जा सकता है।

इससे एजेंट के साथ बातचीत भी बदल जाती है। "ड्रॉपडाउन खराब है" की जगह इनपुट यह बन जाता है कि एक रन चौथे स्टेप तक पहुँचा और वहाँ गलत ऑप्शन चुना हुआ मिला। अब समझने-बूझने को कुछ बचता ही नहीं।

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

लूप बंद होने का एक विस्तृत उदाहरण

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

गड़बड़ फिक्स में नहीं थी। गड़बड़ यह है कि रुक-रुक कर आने वाले बग के सामने एक मैनुअल कोशिश महज़ एक का सैंपल है, और ऐसे बग एक कोशिश में जितनी बार फेल होते हैं, लगभग उतनी ही बार पास भी हो जाते हैं। जो लूप वाकई नतीजे तक पहुँचता है वह अलग दिखता है: पूरे क्रम को एक केस के रूप में लिख लीजिए, उसे कई बार चलाइए, और दर पढ़िए। दस में चार बार फेल होना एजेंट के लिए "यह खराब है" से बिलकुल अलग निर्देश है, क्योंकि यह डिटर्मिनिस्टिक कारणों की पूरी श्रेणी खारिज कर देता है और टाइमिंग की ओर इशारा करता है।

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

वह दावा जिस पर शक करना चाहिए

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

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

जाँच को सेशन के बाद भी ज़िंदा रखिए

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

• GitHub App एक वेबहुक है जिसे आप TestSprite डैशबोर्ड में सेट करते हैं। यह उसी डिप्लॉयमेंट इवेंट को सुनता है जो आपकी पाइपलाइन पहले से पैदा करती है, इसलिए आपकी रिपॉज़िटरी में कुछ भी नहीं बदलता।

• GitHub Actions इस स्टेप को आपके अपने वर्कफ़्लो के भीतर रख देता है, जिसे टर्मिनल से कॉन्फ़िगर किया जाता है।

लूप में वेरिफिकेशन स्टेप आने से क्या बदलता है

लूप में जिस ऑब्ज़र्वेशन की कमी है, TestSprite वही देता है। सेटअप Cursor के भीतर ही एक वेरिफिकेशन स्किल इंस्टॉल कर देता है, ताकि एजेंट खुद केस बना सके, उसे आपके डिप्लॉय किए गए ऐप पर चला सके और नतीजा पढ़ सके — बिना आपके कुछ भी आगे-पीछे पहुँचाए।

डिबगिंग सेशन पर इसका व्यावहारिक असर यह होता है कि राउंड दोहराने बंद हो जाते हैं। एजेंट अब इस पर तर्क नहीं कर रहा होता कि आपको जो दिखा था वह आपको कितना याद है; उसके पास रिकॉर्ड होता है कि क्या आज़माया गया, एप्लिकेशन ने क्या किया, और दोनों कहाँ अलग हुए। वह जो फिक्स सुझाता है, उसकी पुष्टि उस तर्क के अलावा किसी और चीज़ से होती है जिससे वह फिक्स निकला था — और "मैंने ठीक कर दिया" के जानकारी बनने का यही अकेला रास्ता है।

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